СОГЛАШЕНИЯ ПО EV5.

ПРОДОЛЖИТЬ 5.10 (22/07/2019)

1. “…Однако, и сейчас SQL-сервер по умолчанию создаёт кластерный индекс для первичных ключей и, по
старой традиции, физически выстраивает порядок строк.” (https://habr.com/ru/company/oleg-
bunin/blog/348172/)
2. Буферизации записи - ДА, буферизации таблицы – НЕТ.
Обновление БД это по сути передача данных из буфера клиента в SQL сервер. В книге Д. Сэппа «Microsoft
ADO.NET» таким буфером является подмножество основного DataSet 1, состоящее из нескольких записей
нескольких таблиц. В Ev5 будет буфер из одной записи одной таблицы. Почему?
2.1. Представьте себе, что я редактирую иерархический справочник клиентов. Добавил несколько клиентов
в группу «Поставщики» (а буфер не сохранил). Потом перешел в группу «Покупатели» или решил
поставить фильтр, или ….в общем, совершил действия, требующие обновления основного DataSet.
Тогда, чтобы не потерять буфер, я должен передать изменения в БД до того, как обновится основной
DataSet. Это усложняет алгоритм обновления основного DataSet при поиске (навигации) иерархических
данных и уменьшает его изолированность от AED-операций.
2.2. Команда DataAdapter.Update ADO.NET обращается к SQL-серверу для каждой записи буфера
отдельно. По этому при буферизации таблиц, когда изменения множественны и происходят способом
«Изменил запись_1, Изменил запись_2, сохранил запись_1, сохранил запись_2» сопоставим, я
надеюсь, по скорости с буферизаций записи, когда изменения единичны и происходят способом
«Изменил запись_1, сохранил запись_1, Изменил запись_2, сохранил запись_2» 2.
2.3. Когда буфер имеет множество добавленных записей, а первичные ключи надо получать от SQL-
сервера, то усложняется процесс реинтеграции изменений в основной DataSet (см. Д. Сэппа «Microsoft
ADO.NET», стр. 431-437).
ПРИМЕЧАНИЕ. (25/07/2019) ОБЫЧНО СХЕМА ДАННЫХ, В КОТОРОЙ ТРЕБУЕТСЯ МНОЖЕСТВЕННЫЙ
БУФЕР, ИМЕЕТ ТОЛЬКО ОДНО ОТНОШЕНИЕ ТИПА 1:М3. ЕСЛИ В ТАКИХ СХЕМАХ МНЕ НАДО БУДЕТ
ИСПОЛЬЗОВАТЬ МНОЖЕСТВЕННЫЙ БУФЕР, ТО Я БУДУ ИСПОЛЬЗОВАТЬ SEQUENCE НА СТОРОНЕ БД,
ЧТОБЫ ЕЩЕ ДО МОМЕНТА ПЕРЕДАЧИ ИЗМЕНЕНИЙ В БД, ПОЛУЧИТЬ УНИКАЛЬНОЕ ЗНАЧЕНИЕ
КЛЮЧА ДЛЯ РОДИТЕЛЯ И ЕГО ДОЧЕРНИХ ЗАПИСЕЙ. БЛАГО SEQUENCT В 2019 ГОДУ ЕСТЬ И В
ORACLE И В MS SQL.
2.4. Если я редактирую, например OrderDetails, то для «Итого по заказу» не надо писать функцию на
стороне клиента – достаточно вызвать sp_sum_by_order_id (т.к. данные буфера и БД различны только
на время редактирования текущей записи буфера). Общими словами – результат агрегативных
функций на стороне клиента совпадают с результатом соответствующих stored procedures SQL
сервера.
25/07/2019 я
3. Constraints={PrimaryKey,{Unique},{ForeignKey}}

1
основной DataSet это тот, внутри которого пользователю удобно делать редактирование. Для каждой таблицы это
свой DataSet.
2
Это замечание касается и команды TABLEUPDATE() VFP, которая является аналогом команды
DataAdapter.Update ADO.NET.
3
И (ВОЗМОЖНО) НЕСКОЛЬКО ОТНОШЕНИЙ M:1.
20/7/19 решил, что в EV5 внешние ключи всегда будут ссылаться на первичный ключ внешней таблицы. Т.Е.
формулу ссылочной целостности:
Tbl.FKField References RefTbl.RefFld
можно переписать так:
Tbl.FKField References PKTbl, где
PKTbl =RefTbl.PrimaryKey
4. Какую схему данных я буду использовать для изменения («пиклистирования»)
NKI.ID_AKI.
ALTER TABLE Nki FOREIGN KEY Id_Aki REFERENCES Nki – это ссылка на большее кол-во записей. Для
улучшения производительности я хотел ограничиваться периодом (с возможность его прокрутки по дням, неделям,
месяцам, годам). Но 21/07/19 я подумал, что для «пиклистирования» лучше использовать такую схему: Hot -> Hos
-> Nkh ->Nki плюс доп. фильтр, который в момент «пиклистирования» установлен в значение
«дата=дата_документа_в_который_входит текущее значение Nki.Id_Aki», а остальные параметры доп. фильтра -
сброшены. Этот фильтр потом пользователю можно установить, расширив/сузив выборку для поиска нужного
значения Nki.Id_Aki.