Збереження даних. Абстрактний фокус

Першим кроком приводимо дані до табличного виду. Отримуємо табличку з ще з одною табличкою узагальненої інформації.

Проблеми:
1. Можуть мінятись стовбці.
2. Update рядків.
3. Запис узагальненої інформації до «набору даних».

Теперішнє рішення: користуватись БД для малозмінних і невеликих за обсягом даних(до 1 млн. рядків), для решти використовавути файли.

А так би хотілося БД з деревовидною структурою, в якій би ячейка могла мати посилання на свою таблицю.

Чи є якийсь інший варіант збереження даних (хаотично змінних як по рядках так і стовбцях)? Який би був простий у вивчені і доступний у використанні?

Підписуйтеся на Telegram-канал «DOU #tech», щоб не пропустити нові технічні статті

Теми: БД

Ctrl + Enter

Володимир Вержановський 26.01.2018 10:18

Щиро вдячний за коментарії. Гарного дня!!!

Відповісти

Підтримати

Александр Шевченко Java developer 26.01.2018 09:16

Даже тяжело представить для чего такое может потребоваться. Если там все хаотично и не упорядочено, то поиск будет медленным. Наверное монгу какую-то, или почитать stackoverflow.com/...-in-a-relational-database

Vitaliy Fedoriv Java Developer 26.01.2018 09:14

Першим кроком приводимо думки до впорядкованого вигляду...

George 26.01.2018 08:50

Топік так сформульований, неначе списано з якось шкільного підручника з інформатики, який лохи писали.

От чесно.

Олексій Пєніє 26.01.2018 04:46

А ніколи не думав, що файлова система по суті та сама база даних? Дещо інша модель абстракції, але ж у цьому вся перевага: драйверу відверто не цікаво що в тебе в файлах.

Інформаційної моделі хаосу не існує, це випливає із самого означення хаосу.

Mobile 25.01.2018 23:44

есть несколько методов хранения в реляционных — 1. например 3 столбца всегда одинаковы для всех данных, в 4тый столбец пишем все остальные данные key:value, key:value. Вроде МС сервер может даже индексацию делать в таких случаях. Второй вариант — все столбцы таблицы делаем типа строка, но для каждого клиента который пользует таблицу делаем расшифровку данных програмно. Например клиент Вася хранит там номер товара, имя товара и цену, а клиент Петя номер трека, количество закачек и дату выпуска. При таком подходе нельзя делать хорошую индексацию. Ну и последний вариант это подтаблицы, когда в главную таблицу записывается что то типа номер клиента, номер транзакции, дата транзакции, а в дополнительную таблицу созданную конкретно для этого клиента заносится вся остальная информация, естественно подтаблицы могут быть разными, но если ваши данные можна поделить на 5-10-20 классов то их легко раскидывать по подтаблицам классифаером. Для нереляционных типа монго — нада выделить пару основных свойств для индексов и можно писать прямо жисоном

anonymous 25.01.2018 21:11

Костя Третяк 25.01.2018 18:01

Щось ви намудрили зі своєю задачою.

По-перше, перед тим як «приводити дані до табличного виду» необхідно знати в якому вигляді сирі дані.

По-друге, реляційна СУБД точно краще підходить для великих об’ємів, якими ще й маніпулювати треба. І якраз навпаки — коли дані мало змінюються, тоді можна використовувати файли... якщо ви з SQL не дружите.

Із думками вслух типу «так би хотілось» і «варіантом збереження даних, хаотично змінних...» взагалі якась жесть. Думаю вам треба переформулювати питання...

anonymous 25.01.2018 21:05

Костя Третяк

Збереження даних. Абстрактний фокус

9 коментарів

Підписатись на коментарі