Хорошо ли объединить две таблицы базы данных?

Question

Мы работаем на платформе бронирования билетов, где пользователь выбирает количество билетов, заполняет формы участников и производит оплату. На уровне базы данных мы сохраняем запись транзакции для одной транзакции в таблице и нескольких записей участника в другой таблице. Таким образом, связь между таблицей транзакций и таблицей посетителя имеет отношение one to many.

Transaction Таблица:

txnId | order id | buyer name | buyer email | amount | txn_status | attendee json | .... 

Attendee Таблица:

attendeeId | order id | attendee name | attende email | ...... 

Теперь вы можете подумать: "Почему я должен Attendee в JSON таблице транзакций?". Ну, ответ заключается в том, что когда пользователь инициирует транзакцию, мы сохраняем данные участника в json и отмечаем транзакцию как ИНИЦИАТИВ. После успешной транзакции одна и та же транзакция будет отмечена как SUCCESS, и участник json будет сохранен в таблице Attendee. Кроме того, мы используем данные json, чтобы показать посетителям deatils организатору на панели инструментов, таким образом, мы сохранили базу данных, попавшую в таблицу посетителя. И посетитель json не запрашивается, поэтому у нас есть таблица посетителей, чтобы уволить требуемые запросы.

Вопрос: Теперь по какой-то причине мы думаем о слиянии этих таблиц и удалении столбца json. И предположим, что если транзакция началась для 4 участников, мы думаем создать четыре записи транзакций. И у нас есть алгоритм для показа этих записей как один на панели инструментов. Как это повлияет на производительность, если я пойду на этот подход? Каковы будут ваши предложения?

Теперь таблица будет выглядеть следующим образом:

txnId | order id | buyer name | buyer email | amount | txn_status | attendee name | attendee email .... 
1  | 123  | abc  | abc@abc.com | 100 | SUCCESS | xyz   | xyz@xyz.com.... 
2  | 123  | abc  | abc@abc.com | 100 | SUCCESS | pqr   | pqr@pqr.com.... 

Answer 1

Normalization попытки организовать базу данных, чтобы минимизировать избыточность. Используемая вами техника называется denormalization, и она используется для оптимизации таблиц чтения путем добавления избыточных данных во избежание объединения. Это горячо обсуждается, когда денормализация является подходящей.

В вашем случае не должно быть проблем с производительностью с наличием двух таблиц и простым объединением, если ваши внешние ключи индексируются.

Я бы зашел так далеко, что сказал, что вы должны устранить столбец attendee json, так как он избыточен и, скорее всего, выпадет из-за синхронизации, вызвав ошибки. Для таблицы посетителя потребуются триггеры UPDATE, INSERT и DELETE, чтобы поддерживать его в актуальном состоянии, замедляя запись в таблицу. Many databases have built in JSON functions, который может создать JSON очень быстро. Как минимум переместите кешированный JSON в таблицу посетителя.

Кроме того, у вас есть order id как в таблице участников, так и в таблице txn, намекающей на другую избыточность данных. buyer name и buyer email предполагают, что их следует также отделить на другую таблицу, избегая приведения к таблице txn слишком большого объема информации.

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

Возможно, вы сможете дешево выкрикивать некоторые данные из своей базы данных, но вы закладываете свое будущее.Что происходит, когда вы хотите добавить функцию, связанную с информацией о посетителе, и ничего общего с транзакциями? Представьте себе объяснение этого новому разработчику ...

Вы получаете информацию о посетителях из таблицы транзакций ... информацию покупателя. Но один участник может быть частью нескольких транзакций, поэтому вам нужно использовать DISTINCT или GROUP BY ... что замедлит все. Также у них может быть немного другая информация, поэтому вам нужно использовать , вставьте сложный беспорядок здесь, чтобы понять, что все это ... что замедлит все. Почему так? Оптимизация, конечно! Добро пожаловать в компанию!