Лучшая логика для обработки записей Master-Detail

Допустим, у нас есть эти таблицы SQL:

[Articles] 
bill   int         (pkey)
arti   int         (pkey)
name   varchar(50) 

[Bills]
bill   int         (pkey)
fdate  date
uid    int

Предположим, у нас есть список элементов в сетке, представляющий счет:

--------------------------------------------------------------
Id[      15]  Date [01-01-1980]
User [pepe]

Code   Name
----------------------------
1      Something
2      Article name
3      lolololololoolo
4      datadatdatdatdata
5      datadatdatdatdata
--------------------------------------------------------------

Итак, у нас есть заголовок с идентификатором, пользователем, датой и т. д. И затем сетка, заполненная элементами.

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

  1. Зациклите элементы и сделайте запрос, чтобы решить: если существует, это ВСТАВКА, иначе это ОБНОВЛЕНИЕ.
  2. Удалите все элементы (по идентификатору счета), а затем выполните все ВСТАВКИ.

sql master-detail logic
person mRt    schedule 22.06.2010    source источник
comment
Сопоставление между двумя таблицами (Articles является таблицей сетки) и описанием не так ясно, как могло бы быть. Отношения внешнего ключа также весьма важны. Также неясно, что «uid int» представлено как «pepe» в форме заказа. Обратите внимание, что когда пользователь удаляет строку из сетки, вы должны убедиться, что соответствующая строка в таблице «Статьи» также удалена.   -  person Jonathan Leffler    schedule 22.06.2010

Ответы (3)


arrow_upward
2
arrow_downward

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

Производительность

В варианте 1 удаление всех статей займет больше времени.

В варианте 2 добавление без статей к счету с 10 статьями займет столько же времени, сколько добавление 10 статей к счету без статей.

Аудит

Вариант 2 очень сложно проверить

Параллелизм При условии отсутствия обнаружения параллелизма в приложении

Два пользователя открывают счет одновременно. Каждый пользователь добавляет пять статей и нажимает «Сохранить».

В варианте 1 вы получите 10 статей. В варианте 2 вы получите пять.

Я не могу сказать, что правильно.

Эффективность транзакций

При добавлении статей к существующим счетам транзакции будут занимать больше времени, чем необходимо в варианте 2. Это увеличивает вероятность взаимоблокировок для этого варианта использования.

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

В варианте 1 существует вероятность того, что новые статьи могут быть потеряны, а удаленные статьи, которые должны были быть удалены, не удаляются.

В варианте 2 есть вероятность, что все статьи будут потеряны.

person Conrad Frix    schedule 22.06.2010

arrow_upward
3
arrow_downward

Ни один

  • Извлеките данные сетки в XML или создайте/загрузите 2 временные таблицы.
  • Разберите XML в SQL во временную таблицу или прочитайте 2 временные таблицы...
  • Обновите или вставьте (MERGE, ON DUPLICATE и т. д. по мере необходимости)

Оберните записи в обе таблицы в транзакцию

person gbn    schedule 22.06.2010

arrow_upward
1
arrow_downward

Почему бы вам не использовать синтаксис MySQL ON DUPLICATE KEY?

http://dev.mysql.com/doc/refman/5.0/en/insert-on-duplicate.html

 INSERT INTO table (a,b,c) VALUES
 (1,2,3)   ON DUPLICATE KEY UPDATE
 c=c+1;
person Dominique    schedule 22.06.2010