Дизайн базы данных - я должен использовать 30 столбцов или 1 столбец со всеми данными в форме JSON/XML?
Я делаю проект, который должен хранить 30 отдельных полей для бизнес-логики, которые позже будут использоваться для создания отчета для каждого
30 различных полей не записываются одновременно, в бизнес-логике так много транзакций, что будет примерно так:
Transaction 1, update field 1-4
Transaction 2, update field 3,5,9
Transaction 3, update field 8,12, 20-30
...
...
Примечание: каждая транзакция (все принадлежат одной бизнес-логике) будет обновлять произвольное количество полей, а не в каком-либо конкретном порядке.
Мне интересно, какой дизайн моей базы данных будет лучше:
Иметь 30 столбцов в базе данных postgres, представляющих эти 30 различных полей.
Имейте 30 сохраненных хранилищ в форме xml или json и сохраните это только в одном столбце postgres.
1 или 2 какой лучше?
Если я выберу 1>:
Я знаю, что с точки зрения программирования проще, потому что таким образом мне не нужно читать весь xml/json и обновлять только несколько полей, а затем записывать обратно в базу данных, я могу обновить только несколько столбцов, которые мне нужны для каждой транзакции.
Если я выберу 2>:
Я могу потенциально повторно использовать таблицу для чего-то другого, поскольку внутри столбца BLOB-объектов находится только XML. Но неправильно ли использовать универсальный тип таблицы для хранения чего-то совершенно неактуального в бизнес-логике только потому, что в нем есть столбец BLOB-объектов, хранящий xml? Это действительно может сэкономить усилия по созданию нескольких новых таблиц. Но является ли эта общая идея повторного использования таблицы неправильной в СУБД?
Также, выбрав 2> кажется, я смогу справиться с потенциальными изменениями, такими как изменение определенного поля / добавление дополнительного поля? По крайней мере, мне кажется, что мне не нужно менять таблицу базы данных. Но мне все еще нужно изменить код C++ & C# для внутренней обработки изменений, не уверен, что это какое-то преимущество.
У меня недостаточно опыта в проектировании баз данных, поэтому я не могу принять решение, какой из них выбрать. Любой вклад приветствуется.
Обратите внимание, что есть большая вероятность, что мне пока не нужно выполнять индексирование или поиск по этим 30 столбцам, для дополнительного столбца будет создан первичный ключ, если я выберу 2>. Но я не уверен, что позже мне потребуется выполнить поиск по любому из этих столбцов / полей.
В основном все мои поля предопределены из документов требований, они, как правило, любят простое поле:
field1: value(max len 10)
field2: value(max len 20)
...
field20: value((max len 2)
Нет гнездовых полей. Стоит ли создавать 20 столбцов для каждого из этих полей (некоторые являются строковыми, например дата / время, некоторые являются строковыми, некоторые целыми и т. Д.).
2> Является ли размещение другой бизнес-логики в разделяемой таблице плохой дизайнерской идеей? Если это только положить в общую таблицу, потому что они имеют одинаковую структуру? Например, все они имеют столбец даты и времени, первичный ключ и столбец xml с различной бизнес-логикой внутри? Таким образом, мы берем на себя некоторые усилия по созданию новых таблиц... Стоит ли это экономить?
3 ответа
В целом, целесообразно разделить документ JSON или XML и сохранить его в виде отдельных столбцов. Это дает вам возможность устанавливать ограничения на столбцы для проверки и проверки, индексировать столбцы, использовать соответствующие типы данных для каждого поля и в целом использовать возможности базы данных.
Сопоставить его с объектами обычно не сложно, поскольку для этого существует множество инструментов. Например, Java предлагает JAXB и JPA.
Основное время разделения - не самая лучшая идея, когда вы заранее не знаете, какими будут поля документа JSON или XML или сколько их будет. В этом случае у вас есть только два варианта - использовать EAV-подобную модель данных или сохранить документ непосредственно в качестве поля базы данных.
В этом случае (и только в этом случае) я бы рассмотрел хранение документа в базе данных напрямую. Поддержка SQL/XML в PostgreSQL означает, что вы все еще можете создавать индексы выражений в xpath выражения, и вы можете использовать триггеры для некоторой проверки.
Это не хороший вариант, просто EAV обычно еще хуже.
Если документ "плоский", то есть один уровень ключей и значений, без вложенности, можно сохранить его как hstore вместо этого, как hstore тип данных намного более мощный.
Всегда храните ваши поля XML/JSON как отдельные поля в реляционной базе данных. Делая это, вы будете поддерживать свою базу данных в нормальном состоянии, позволяя базе данных выполнять свои функции с запросами / индексами и т. Д. И вы избавите других разработчиков от головной боли при расшифровке поля XML/JSON.
Будет больше работы по извлечению полей из XML/JSON и, возможно, по поддержанию его, если поля будут добавлены, но как только вы создадите класс или классы для этого, препятствие будет устранено, и это будет более чем на загадочное поле blob.
(1) является более стандартным, по уважительным причинам. Позволяет базе данных выполнять тяжелую работу по поиску и индексации с одной стороны.