Принимайте участие в зарплатном опросе! Уже собрано почти 8 000 анкет.
×Закрыть

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

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

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

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

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

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

LinkedIn
Допустимые теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Допустимые теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter

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

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

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

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

От чесно.

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

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

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

Во первых нет никаких проблем с хранением

хаотично змінних як по рядках так і стовбцях

в ноСКЛ, но есть проблема с структуризированной обработкой и извлеченим, да и обновлением тоже.
Какого типа данные?
Я бы вам посоветовал гибридный подход в реляционной базе:
— Кор структуру таблиц (а именно колонок, я так понимаю именно с ними проблемы) — которая не должна меняться никогда (либо достаточно редко что позволит вручную обновлять структуру таблицы раз в пол года) создаем как обычную нормализованную реляционную сктрутуру.
— А вот к ней добавляем либо одну длинную таблицу в которой данные развернуты вертикально и название колонки хранится как key-value pair типа такого
|table_name|table_record_pkey_id|column_name|column_value|create_timestamp| update_timestamp| batch| etc...
— либо второй вариант — к каждой статической таблицы создаете по сателит таблице с уже вышеописанным методом хранения данных
Вариантов можно придумать еще кучу, но без точных исходных данных — хрен поймешь что вам надо

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

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

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

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

я кажется понял в чем дело, из всей этой белиберды вот это важное предложение

хаотично змінних як по рядках так і СТОВБЦЯХ

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