Как организовать структуру БД для электронных журналов?

Question

[AntoxaVolkov]

Всем привет!
Мне нужно создать электронные журналы (таблицы) со следующими возможностями:

1. Создание нового журнала
   
   1. Название журнала
      
   2. Создание полей
      
   3. Выбор типа для каждого поля
      
   4. Возможность связывать поле журнала с полем других журналов по определённым условиям
      
   5. И др.
      
   
   
2. Редактирование
   
3. Удаление
   
4. Ведение журнала (заполнение строк)
   

Пока нашел два решения. Первое, создать три таблицы: журналы(id, name), поля(id, id_журнала, название, тип, и т.д), строки (id, id_журнала, json c с данными строки {id_поля:data,id_поля:data}).
Второе, каждый новый журнал, новая таблица, а свойства полей хранятся в отдельной таблице "поля" (id, name_table, name_поля, тип, и т.д.)

Подскажите какое решение лучше и почему, или может есть более хорошее решение.
Журналов может быть десятки, полей сотни, а строк десятки тысяч. А если приложения будут использовать и другие отделения, тогда журналов сотни, полей десятки тысяч, а строк миллионы. Следовательно крайне важна производительность.

Разрабатываю на Laravel + Mysql.

Answer 1

[Adamos]

Я бы начинал думать с вопроса "а зачем здесь именно реляционная база данных и что от нее на самом деле потребуется?".
Если не знаете ответа - присмотритесь к базам, специально заточенным под хранение документов.

Comments

[AntoxaVolkov]

Я не уверен что в нашей организации смогут поставить какие то другие бд. А MySQL уже используется как в организации так и в этом проекте. Но если все же задуматься о другой БД. То, что бы вы посоветовали, с бесплатной лицензией, и что бы можно было совместить с laravel и mysql (здесь уже хранятся пользователи и другие данные).

[Adamos]

AntoxaVolkov: Могу посоветовать погуглить - сам я с такими решениями тоже дела не имел.
Но могу предложить и альтернативный взгляд: если индексация внутренностей журналов некритична и работают с ними только целиком, то зачем их вообще запихивать в базу? Храните описание в базе, а сами журналы - в файлах. Для таблиц это может быть как простой CSV или XML, так и что-то из офисных форматов. Или создать собственный формат на базе CSV, например, описывая поля в первой строке. Развяжете себе руки...

[AntoxaVolkov]

Adamos: Интересный вариант, спасибо, подумаю над этим.

Answer 2

[Draconian]

Теоретически, json в отдельном поле нарушает атомарность данных. Если вы собираетесь так их хранить, то реляционная БД вам, возможно, и не нужна.
Второй вариант для реляционных БД вполне юзабельный, нагрузка зависит от железа, на котором будет работать СУБД + кэширование, индексы, вот это всё.

Если хотите идти по реляционному пути, на мой взгляд, лучше сделать так - в одной таблице хранить журналы (PK journal_id, name), в другой поля журналов (FK journal_id), в третьей значения полей без json (FK field_id). Связи везде один ко многим - у одного журнала много полей, у одного поля - много значений.

Ваш вариант тоже рабочий, но есть небольшой минус - добавление полей будет осуществляться через alter table, насколько я понял.

Comments

[AntoxaVolkov]

Я думал над вариантом без json, но что то я так и не смог сообразить как потом собирать строки, мы знаем какому полю принадлежит значение, какому журналу тоже знаем, а какой строке? Может я туплю, но не как не могу сообразить как это сделать без четвёртой таблицы.

[Draconian]

AntoxaVolkov: да, вы правы. Тогда ваш вариант будет лучше.