Влияние на производительность хранения полей в виде отдельной строки JSON текстового типа по сравнению с разделением на отдельные таблицы

Question

У меня есть таблица с именем Billing, которая в основном является квитанцией (для разных типов транзакций). В приложении есть функция, позволяющая создавать новые сборы (ну, все сборы, кроме налоговых и прочих констант). Поскольку количество сборов будет динамическим, мы решили хранить сборы за биллинг в одном текстовом поле со структурой JSON. Таким образом, столбец Charges содержит такие вещи:

{"CrateFee":50,"DeliveryFee":90,"PackagingFee":20}
{"DeliveyFee":90,"ServiceCharge":200}

Наш альтернативный вариант - создать отдельную таблицу для этих сборов с такой структурой:

Charges
BillingId | ChargeName |  ChargeValue
1           CrateFee      50
1           DeliveryFee   90
1           PackagingFee  20
2           DeliveryFee   90
2           ServiceCharge 200

Мы решили отказаться от второго метода, потому что он будет заполняться десятками тысяч строк всего за один день (оценка составляет около тысячи транзакций в день). Я знаю, что мы будем ограничены тем, что мы можем сделать с данными, если будем использовать первый, поэтому я действительно хочу использовать метод отдельных таблиц. Но я не имею представления о масштабировании, оптимизации и т. Д., Когда речь заходит о базах данных, поэтому мне нужна помощь в этом.

Можно ли использовать второй метод? Как это повлияет на производительность? Есть ли другие альтернативы?

Answer 1

Первая реализация может упростить хранение данных в одну строку, но вы открываете себя для целого мира боли .

При правильном использовании индексов на полях у вас не должно быть серьезных проблем, поэтому я рекомендую второй подход.

Также на более позднем этапе вы можете попробовать реализовать архивирование , что также должно помочь с размером второй таблицы.

Answer 2

нормально ли использовать второй метод?

Мне еще предстоит встретиться с администратором базы данных, который позволил бы сохранять формат JSON в своей базе данных, включая меня самого.

В приложении есть функция, позволяющая создавать новые платежи

Для правильной нормализации я бы предложил отдельную таблицу, содержащую типы платежей. Пользователи по-прежнему могут добавлять в него типы платежей, и вы будете использовать внешний ключ для ссылки на тип оплаты - точно так же, как вы делаете с billingid.

Самая большая причина разбить сборы на строки заключается в простоте доступа к данным для составления отчетов и т. Д. Вы все еще можете сделать это с форматом JSON, но вы будете рассматривать манипуляции со строками, и, поскольку это текст произвольной формы, есть риск, что вы не сможете сгруппировать по именам платежей. Не берите в голову производительность выполнения этой манипуляции строки. Это не стоит хлопот - сделайте это правильно, используйте вариант 2.

Возможно, вы захотите сохранить в таблице также налог (по крайней мере, процент) - налоги со временем меняются, поэтому вам нужно знать, какой налог был на момент покупки, чтобы точно воспроизвести счет на более поздний срок.

Answer 3

Если вы воспользуетесь первым предложением, с вашим приложением будет ужасно работать, а производительность поразит вас своей ужасностью, и пользователи придут к вам, чтобы задушить вас. (Хорошо, так что там немного гиперболы).

Самое первое правило проектирования базы данных - хранить только один фрагмент информации в каждом поле.

С первым дизайном, когда вам нужно знать, сколько каждый клиент потратил по типам платежей, вы не сможете легко или быстро получить эти данные.

Вам нужна таблица с названием «Типы начислений», в которой содержатся определения типов. Если пользователь добавляет новый, он попадает в эту таблицу. Тогда у вас есть таблица расходов, аналогичная показанной во втором примере. Сохраняя стандартные типы и делая их болезненными, но при этом добавляя их, становится менее вероятным, что у вас будет 4317 типов начислений, которые означают одно и то же. Это важно позже, когда вы хотите создавать отчеты по данным в вашей базе данных.

У вас будет значительно лучшая производительность при запросе второй возможности, чем первой, при условии правильного индексирования.

Если ваша организация честно даже подумала об использовании первой структуры, то вам необходимо немедленно нанять опытного dba, поскольку существует явное недопонимание относительно того, как проектировать базу данных. Если вы ожидаете тысячи ежедневных платежей, вам нужно учитывать производительность в дизайне, а не повышать ее позже. Оптимальная оптимизация не означает, что оптимизация вообще не рассматривается. Производительность базы данных - это одна из трех самых важных вещей, которые вам нужно спроектировать (две другие - это целостность данных и безопасность).