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

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

0 голосов
/ 22 июня 2010

Допустим, у нас есть следующие таблицы 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. Зациклить элементы и сделать запрос, чтобы решить: существует ли INSERT, иначе - ОБНОВЛЕНИЕ.
  2. Удалить все элементы (по идентификатору счета)), а затем сделайте все ВСТАВКИ.

Ответы [ 3 ]

3 голосов
/ 22 июня 2010

Ни

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

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

2 голосов
/ 22 июня 2010

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

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

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

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

Аудиторская

Вариант 2 очень сложен для аудита

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

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

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

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

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

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

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

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

В варианте 2 существует вероятность потери всех статей

1 голос
/ 22 июня 2010

Почему вы не используете синтаксис 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;
...