Добро пожаловать в форум, Guest >> Войти | Регистрация | Поиск | Правила | | В избранное | Подписаться | ||
Все форумы / Firebird, InterBase |
![]() ![]() |
Топик располагается на нескольких страницах: ←Ctrl назад 1 .. 19 20 21 22 23 [24] 25 26 27 28 .. 55 вперед Ctrl→ |
rdb_dev Member Откуда: с болот Сообщений: 3604 |
|
||||
23 янв 19, 16:27 [21792412] Ответить | Цитировать Сообщить модератору |
hvlad Member Откуда: Сообщений: 11135 |
rdb_dev, если ты думаешь, что стало понятнее - ты очень ошибаешься |
23 янв 19, 16:30 [21792421] Ответить | Цитировать Сообщить модератору |
rdb_dev Member Откуда: с болот Сообщений: 3604 |
|
||
23 янв 19, 16:30 [21792422] Ответить | Цитировать Сообщить модератору |
rdb_dev Member Откуда: с болот Сообщений: 3604 |
Накидываем данные в дочерние таблицы, триггеры на вставку в дочерние таблицы сделали SELECT ... FROM <master_table> WITH LOCK, затем транзакцию закоммитили, а потом стартанули другую транзакцию и поменяли в ней значение опорного поля, в результате чего, данные в дочерних таблицах, сформированные/проверенные по значению опорного поля в мастер таблице оказались рассогласованы с новым значением. |
||
23 янв 19, 16:40 [21792434] Ответить | Цитировать Сообщить модератору |
Vlad F Member Откуда: Сообщений: 1335 |
Походу аффтар который сделает неконсистентными детали. Отсюда вывод, - или триггеры у него те кругом кривые, или общая структурная концепция (не исключено, впрочем, что и то и другое)). |
23 янв 19, 16:41 [21792437] Ответить | Цитировать Сообщить модератору |
hvlad Member Откуда: Сообщений: 11135 |
|
||
23 янв 19, 17:18 [21792489] Ответить | Цитировать Сообщить модератору |
Симонов Денис Member Откуда: Рязань Сообщений: 10733 |
rdb_dev, открой для себя статусы документов. Ничего что шапку документа с твоим опорным полем можно поменять и после того как ты все детальки заполнишь? |
23 янв 19, 17:23 [21792509] Ответить | Цитировать Сообщить модератору |
Dimitry Sibiryakov Member Откуда: Сообщений: 52116 |
А ещё нормализацию. Ибо изменяемые поля в одной таблице, зависящие от полей другой таблицы есть нарушение третьей НФ. Posted via ActualForum NNTP Server 1.5 |
||
23 янв 19, 17:30 [21792520] Ответить | Цитировать Сообщить модератору |
Старый плюшевый мишка Member Откуда: Сообщений: 911 |
Ууууу, как всё запущено... |
||||
23 янв 19, 17:50 [21792544] Ответить | Цитировать Сообщить модератору |
rdb_dev Member Откуда: с болот Сообщений: 3604 |
|
||||||
24 янв 19, 09:46 [21792905] Ответить | Цитировать Сообщить модератору |
Vlad F Member Откуда: Сообщений: 1335 |
rdb_dev, Фича твоя, концептуальная, полное, имхо, барахло. Тебе просто нужен новый триггер на мастера, который при изменении определенных полей поднимет и разравняет детали. Фтопку ее, а пиво предлагаю отдать мне.)) |
24 янв 19, 09:54 [21792922] Ответить | Цитировать Сообщить модератору |
rdb_dev Member Откуда: с болот Сообщений: 3604 |
В каком месте примера ниже денормализация? Все неключевые атрибуты, кроме штампа времени, объединены в уникальную комбинацию, обеспечивающую условие "неключевые атрибуты"<=>"ключ", что и является условием 3NF: CREATE TABLE "map" ( "tmstmp" TMSTMP NOT NULL, "id" ID NOT NULL, "class_id" ID NOT NULL, "node_id" ID DEFAULT NULL, CONSTRAINT "map__pk" PRIMARY KEY ("id"), CONSTRAINT "map__uq" UNIQUE ("node_id", "class_id"), CONSTRAINT "map__fk__node_id" FOREIGN KEY ("node_id") REFERENCES "map_uuid" ("map_id") ON UPDATE CASCADE ON DELETE CASCADE, CONSTRAINT "map__fk__class_id" FOREIGN KEY ("class_id") REFERENCES "classes" ("id") ON UPDATE CASCADE ON DELETE CASCADE, ); CREATE TABLE "map_seq" ( "tmstmp" TMSTMP NOT NULL, "seq_id" ID NOT NULL, "map_id" ID NOT NULL, "order" SMALLINT NOT NULL, CONSTRAINT "map_seq__pk" PRIMARY KEY ("seq_id"), CONSTRAINT "map_seq__uq" UNIQUE ("map_id", "order"), CONSTRAINT "map_seq__fk__map" FOREIGN KEY ("map_id") REFERENCES "map" ("id") ON UPDATE CASCADE ON DELETE CASCADE ); |
||||
24 янв 19, 10:06 [21792944] Ответить | Цитировать Сообщить модератору |
rdb_dev Member Откуда: с болот Сообщений: 3604 |
|
||||
24 янв 19, 10:10 [21792948] Ответить | Цитировать Сообщить модератору |
Симонов Денис Member Откуда: Рязань Сообщений: 10733 |
Вот это борьба за пиво ![]() ИХМО идея полная хрень |
24 янв 19, 10:41 [21793010] Ответить | Цитировать Сообщить модератору |
rdb_dev Member Откуда: с болот Сообщений: 3604 |
![]() Под пиво я предлагал передачу наборов строк между SP и/или клиент-EB как некую альтернативу временным таблицам. |
||
24 янв 19, 10:51 [21793023] Ответить | Цитировать Сообщить модератору |
Vlad F Member Откуда: Сообщений: 1335 |
rdb_dev, Однако, пока ничуть не убедил. Тем более, что из представленных DDL по прежнему никуя не понятно, что ты там собрался править в деталях при изменениях мастера. Уж не "tmstmp" ли? |
24 янв 19, 12:01 [21793129] Ответить | Цитировать Сообщить модератору |
rdb_dev Member Откуда: с болот Сообщений: 3604 |
Своё ИМХО по поводу обновления данных дочерних таблиц из триггеров мастер-таблицы я изложил и на мой взгляд, концепция вполне ясна. На сколько это актуально и нужно - пусть решают разработчики. |
||
24 янв 19, 12:06 [21793141] Ответить | Цитировать Сообщить модератору |
hvlad Member Откуда: Сообщений: 11135 |
Отличный метод, продолжай в том же духе :) |
||||
24 янв 19, 12:17 [21793163] Ответить | Цитировать Сообщить модератору |
rdb_dev Member Откуда: с болот Сообщений: 3604 |
В мастер таблицу вносятся изменения, но PK остается прежним и надо как-то сообщить триггерам дочерних таблиц, что в мастер внесены изменения. Я предложил "подёргать за хвост" через симуляцию каскадного изменения PK->FK. |
||||||
24 янв 19, 12:22 [21793172] Ответить | Цитировать Сообщить модератору |
hvlad Member Откуда: Сообщений: 11135 |
б) триггер ON UPDATE |
||
24 янв 19, 12:24 [21793177] Ответить | Цитировать Сообщить модератору |
rdb_dev Member Откуда: с болот Сообщений: 3604 |
![]()
|
||||||||
24 янв 19, 13:00 [21793244] Ответить | Цитировать Сообщить модератору |
Симонов Денис Member Откуда: Рязань Сообщений: 10733 |
rdb_dev, ну это уже откровенная чушь пошла. Смотри 1. На мастер таблицу триггеров можно написать скоко хошь 2. Триггеры можно вызвать только изменив что-то, это тебе не процедуры. Кстати всякие WITH LOCK никакие триггеры не дёргают к счастью 3. Передёргивать тысячи привязанных записей это зло. Проще такие вещи запретить концептуально |
24 янв 19, 13:08 [21793258] Ответить | Цитировать Сообщить модератору |
Фэйтл Эра Member Откуда: Сообщений: 615 |
Меняешь определение "концептуальности", и всё. Например: добавляешь новую "дочернюю" таблицу? Добавь к "родительской" таблице еще один триггер. Хотя,
- от бардака ничто не спасет. |
||||
24 янв 19, 13:08 [21793260] Ответить | Цитировать Сообщить модератору |
Vlad F Member Откуда: Сообщений: 1335 |
rdb_dev, Я понял!!- сделай специальную "трубу" через отдельное поле и у мастера и у детали, соединенное каскадом на апдейт, для именно такого "подергивания", и не морочь нам больше голову.)) P.S. Пиво, однозначно, мое.)) |
24 янв 19, 13:15 [21793274] Ответить | Цитировать Сообщить модератору |
hvlad Member Откуда: Сообщений: 11135 |
rdb_dev, я уже говорил, что бизнес-логика на триггерах - ад ? Всё ещё есть сомнения ? Ты предлагаешь решение своей частной архитектурной проблемы вынести на общий системный уровень. Вместо того, чтобы исправить своё прикладное решение. Даже если пойти у тебя на поводу и добавить это в движок, это не спасёт тебя от десятков других отрицательных последствий выбранной архитектуры. А всё от того, что - см. выше |
24 янв 19, 13:16 [21793276] Ответить | Цитировать Сообщить модератору |
Топик располагается на нескольких страницах: ←Ctrl назад 1 .. 19 20 21 22 23 [24] 25 26 27 28 .. 55 вперед Ctrl→ |
Все форумы / Firebird, InterBase | ![]() |