Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Firebird, InterBase Новый топик    Ответить
Топик располагается на нескольких страницах: Ctrl  назад   1 .. 19 20 21 22 23 [24] 25 26 27 28 .. 53   вперед  Ctrl
 Re: Конкурс идей про Firebird  [new]
rdb_dev
Member

Откуда: с болот
Сообщений: 3079
hvlad
rdb_dev
в один прекрасный момент кто-то может изменить данные в мастер таблице, на которые опираются данные в дочерней
что ? мастер же залочен, не ?
Не в той же самой транзакции, а когда-нибудь потом.
23 янв 19, 16:27    [21792412]     Ответить | Цитировать Сообщить модератору
 Re: Конкурс идей про Firebird  [new]
hvlad
Member

Откуда:
Сообщений: 10727
rdb_dev,

если ты думаешь, что стало понятнее - ты очень ошибаешься
23 янв 19, 16:30    [21792421]     Ответить | Цитировать Сообщить модератору
 Re: Конкурс идей про Firebird  [new]
rdb_dev
Member

Откуда: с болот
Сообщений: 3079
hvlad
На всякий, напомню: бизнес-логика на триггерах - путь в ад.
Дык кудыж без неё? Консистентность и согласованность цэж наше ффсё!
23 янв 19, 16:30    [21792422]     Ответить | Цитировать Сообщить модератору
 Re: Конкурс идей про Firebird  [new]
rdb_dev
Member

Откуда: с болот
Сообщений: 3079
hvlad
rdb_dev,
если ты думаешь, что стало понятнее - ты очень ошибаешься
Вот те раз...
Накидываем данные в дочерние таблицы, триггеры на вставку в дочерние таблицы сделали SELECT ... FROM <master_table> WITH LOCK, затем транзакцию закоммитили, а потом стартанули другую транзакцию и поменяли в ней значение опорного поля, в результате чего, данные в дочерних таблицах, сформированные/проверенные по значению опорного поля в мастер таблице оказались рассогласованы с новым значением.
23 янв 19, 16:40    [21792434]     Ответить | Цитировать Сообщить модератору
 Re: Конкурс идей про Firebird  [new]
Vlad F
Member

Откуда:
Сообщений: 1081
Походу аффтар нацелившийся на местную шнобелевскую премию намекает на такой апдейт мастера,
который сделает неконсистентными детали. Отсюда вывод, - или триггеры у него те кругом кривые,
или общая структурная концепция (не исключено, впрочем, что и то и другое)).
23 янв 19, 16:41    [21792437]     Ответить | Цитировать Сообщить модератору
 Re: Конкурс идей про Firebird  [new]
hvlad
Member

Откуда:
Сообщений: 10727
rdb_dev
потом стартанули другую транзакцию и поменяли в ней значение опорного поля, в результате чего, данные в дочерних таблицах, сформированные/проверенные по значению опорного поля в мастер таблице оказались рассогласованы с новым значением.
И при чём тут СУБД ?
23 янв 19, 17:18    [21792489]     Ответить | Цитировать Сообщить модератору
 Re: Конкурс идей про Firebird  [new]
Симонов Денис
Member

Откуда: Рязань
Сообщений: 10304
rdb_dev,

открой для себя статусы документов. Ничего что шапку документа с твоим опорным полем можно поменять и после того как ты все детальки заполнишь?
23 янв 19, 17:23    [21792509]     Ответить | Цитировать Сообщить модератору
 Re: Конкурс идей про Firebird  [new]
Dimitry Sibiryakov
Member

Откуда:
Сообщений: 49139

Симонов Денис
открой для себя статусы документов.

А ещё нормализацию. Ибо изменяемые поля в одной таблице, зависящие от полей другой таблицы
есть нарушение третьей НФ.

Posted via ActualForum NNTP Server 1.5

23 янв 19, 17:30    [21792520]     Ответить | Цитировать Сообщить модератору
 Re: Конкурс идей про Firebird  [new]
Старый плюшевый мишка
Member

Откуда:
Сообщений: 754
rdb_dev
hvlad
rdb_dev,
если ты думаешь, что стало понятнее - ты очень ошибаешься
Вот те раз...
Накидываем данные в дочерние таблицы, триггеры на вставку в дочерние таблицы сделали SELECT ... FROM <master_table> WITH LOCK, затем транзакцию закоммитили, а потом стартанули другую транзакцию и поменяли в ней значение опорного поля, в результате чего, данные в дочерних таблицах, сформированные/проверенные по значению опорного поля в мастер таблице оказались рассогласованы с новым значением.
\

Ууууу, как всё запущено...
23 янв 19, 17:50    [21792544]     Ответить | Цитировать Сообщить модератору
 Re: Конкурс идей про Firebird  [new]
rdb_dev
Member

Откуда: с болот
Сообщений: 3079
Vlad F
Походу аффтар нацелившийся на местную шнобелевскую премию намекает на такой апдейт мастера,
который сделает неконсистентными детали. Отсюда вывод, - или триггеры у него те кругом кривые,
или общая структурная концепция (не исключено, впрочем, что и то и другое)).
Позволь, мне ответить цитатой:
rdb_dev
m7m
Читал, читал и так и не понял чем триггер ... UPDATE на мастер таблице не угодил?
Триггер на мастер таблице не угодил тем, что с точки зрения концепции иерархии и модульности, этот триггер не должен знать - сколько у мастер таблицы дочерних таблиц и какие нужно дёргать ХП, чтобы согласовать данные при внесении изменений в опорные поля. Представь себе ситуацию, когда над БД работают несколько разработчиков - один создал мастер таблицу, дцать других разработчиков понаклепали к ней кучу дочерних таблиц и реализовали какую-то бизнес-логику. Как быть? Просить первого разработчика внести в триггер своей таблицы соответствующие изменения или другим разработчикам раздать номера триггеров на мастер таблицу, чтобы каждый из них сам написали свой триггер к мастер таблице? Вариант так себе... Гораздо проще разработчику из своего триггера мастер-таблицы дёрнуть оператор, симулирующий изменение ключевого поля, а реализованная в триггерах дочерних таблиц бизнес-логика отработает с учётом изменений, внесенных в опорные поля мастер таблицы.
Я говорю о концептуальной фиче, позволяющей дёргать триггеры дочерних таблиц через симуляцию изменения FK дочерних таблиц по изменения PK мастер таблицы, а не о том, как я конкретно сейчас решаю эту задачу на ФБ2.5 (как я делаю сейчас, мне не нравится).
24 янв 19, 09:46    [21792905]     Ответить | Цитировать Сообщить модератору
 Re: Конкурс идей про Firebird  [new]
Vlad F
Member

Откуда:
Сообщений: 1081
rdb_dev,

Фича твоя, концептуальная, полное, имхо, барахло. Тебе просто нужен новый триггер на мастера,
который при изменении определенных полей поднимет и разравняет детали.
Фтопку ее, а пиво предлагаю отдать мне.))
24 янв 19, 09:54    [21792922]     Ответить | Цитировать Сообщить модератору
 Re: Конкурс идей про Firebird  [new]
rdb_dev
Member

Откуда: с болот
Сообщений: 3079
Dimitry Sibiryakov
Симонов Денис
открой для себя статусы документов.

А ещё нормализацию. Ибо изменяемые поля в одной таблице, зависящие от полей другой таблицы
есть нарушение третьей НФ.
Во-первых, моё предложение к 3NF не относится. Во-вторых - ты уверен, что правильно понимаешь 3NF?
В каком месте примера ниже денормализация? Все неключевые атрибуты, кроме штампа времени, объединены в уникальную комбинацию, обеспечивающую условие "неключевые атрибуты"<=>"ключ", что и является условием 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]     Ответить | Цитировать Сообщить модератору
 Re: Конкурс идей про Firebird  [new]
rdb_dev
Member

Откуда: с болот
Сообщений: 3079
Vlad F
rdb_dev,
Фича твоя, концептуальная, полное, имхо, барахло. Тебе просто нужен новый триггер на мастера,
который при изменении определенных полей поднимет и разравняет детали.
Еще раз - лепить на местер таблицу триггер, обновляющий дочерние таблицы, ИМХО, плохо, а почему именно плохо, я уже изложил!
Vlad F
Фтопку ее, а пиво предлагаю отдать мне.))
Я не за ради пива... :) И да - пиво предлагаю отдать тебе!
24 янв 19, 10:10    [21792948]     Ответить | Цитировать Сообщить модератору
 Re: Конкурс идей про Firebird  [new]
Симонов Денис
Member

Откуда: Рязань
Сообщений: 10304
Вот это борьба за пиво

ИХМО идея полная хрень
24 янв 19, 10:41    [21793010]     Ответить | Цитировать Сообщить модератору
 Re: Конкурс идей про Firebird  [new]
rdb_dev
Member

Откуда: с болот
Сообщений: 3079
Симонов Денис
Вот это борьба за пиво

ИХМО идея полная хрень
Да не надо мне пиво! Нельзя мне...
Под пиво я предлагал передачу наборов строк между SP и/или клиент-EB как некую альтернативу временным таблицам.
24 янв 19, 10:51    [21793023]     Ответить | Цитировать Сообщить модератору
 Re: Конкурс идей про Firebird  [new]
Vlad F
Member

Откуда:
Сообщений: 1081
rdb_dev,

Однако, пока ничуть не убедил. Тем более, что из представленных DDL по прежнему никуя не понятно,
что ты там собрался править в деталях при изменениях мастера. Уж не "tmstmp" ли?
24 янв 19, 12:01    [21793129]     Ответить | Цитировать Сообщить модератору
 Re: Конкурс идей про Firebird  [new]
rdb_dev
Member

Откуда: с болот
Сообщений: 3079
Vlad F
rdb_dev,

Однако, пока ничуть не убедил. Тем более, что из представленных DDL по прежнему никуя не понятно,
что ты там собрался править в деталях при изменениях мастера. Уж не "tmstmp" ли?
Забей!
Своё ИМХО по поводу обновления данных дочерних таблиц из триггеров мастер-таблицы я изложил и на мой взгляд, концепция вполне ясна. На сколько это актуально и нужно - пусть решают разработчики.
24 янв 19, 12:06    [21793141]     Ответить | Цитировать Сообщить модератору
 Re: Конкурс идей про Firebird  [new]
hvlad
Member

Откуда:
Сообщений: 10727
rdb_dev
на мой взгляд, концепция вполне ясна
Гм
rdb_dev
На сколько это актуально и нужно - пусть решают разработчики.
Которые явно говорят, что нихрена не поняли

Отличный метод, продолжай в том же духе :)
24 янв 19, 12:17    [21793163]     Ответить | Цитировать Сообщить модератору
 Re: Конкурс идей про Firebird  [new]
rdb_dev
Member

Откуда: с болот
Сообщений: 3079
hvlad
rdb_dev
на мой взгляд, концепция вполне ясна
Гм
rdb_dev
На сколько это актуально и нужно - пусть решают разработчики.
Которые явно говорят, что нихрена не поняли

Отличный метод, продолжай в том же духе :)
Чо тут понимать?
В мастер таблицу вносятся изменения, но PK остается прежним и надо как-то сообщить триггерам дочерних таблиц, что в мастер внесены изменения. Я предложил "подёргать за хвост" через симуляцию каскадного изменения PK->FK.
24 янв 19, 12:22    [21793172]     Ответить | Цитировать Сообщить модератору
 Re: Конкурс идей про Firebird  [new]
hvlad
Member

Откуда:
Сообщений: 10727
rdb_dev
В мастер таблицу вносятся изменения, но PK остается прежним и надо как-то сообщить триггерам дочерних таблиц, что в мастер внесены изменения.
а) при чём тут PK
б) триггер ON UPDATE
24 янв 19, 12:24    [21793177]     Ответить | Цитировать Сообщить модератору
 Re: Конкурс идей про Firebird  [new]
rdb_dev
Member

Откуда: с болот
Сообщений: 3079
hvlad
rdb_dev
В мастер таблицу вносятся изменения, но PK остается прежним и надо как-то сообщить триггерам дочерних таблиц, что в мастер внесены изменения.
а) при чём тут PK
б) триггер ON UPDATE
Да, блин, чтож такое?!...
rdb_dev
m7m
Читал, читал и так и не понял чем триггер ... UPDATE на мастер таблице не угодил?
Триггер на мастер таблице не угодил тем, что с точки зрения концепции иерархии и модульности, этот триггер не должен знать - сколько у мастер таблицы дочерних таблиц и какие нужно дёргать ХП, чтобы согласовать данные при внесении изменений в опорные поля. Представь себе ситуацию, когда над БД работают несколько разработчиков - один создал мастер таблицу, дцать других разработчиков понаклепали к ней кучу дочерних таблиц и реализовали какую-то бизнес-логику. Как быть? Просить первого разработчика внести в триггер своей таблицы соответствующие изменения или другим разработчикам раздать номера триггеров на мастер таблицу, чтобы каждый из них сам написали свой триггер к мастер таблице? Вариант так себе... Гораздо проще разработчику из своего триггера мастер-таблицы дёрнуть оператор, симулирующий изменение ключевого поля, а реализованная в триггерах дочерних таблиц бизнес-логика отработает с учётом изменений, внесенных в опорные поля мастер таблицы.
Условимся, что триггер мастер таблицы ничего не знает о том, сколько дочерних таблиц у обрабатываемой им мастер таблицы и есть ли они вообще, да и не должен знать концептуально! Но этот триггер может предполагать, что дочерние таблицы, таки, имеются и что в своих FK эти таблицы имеют ON UPDATE CASCADE. Как сообщить триггерам дочерних таблиц о том, что в мастер таблицу внесены изменения? Вариант - "подёргать за хвост" FK дочерних таблиц - за PK мастер таблицы, но так, чтобы значение PK не изменилось, т.е. симулировать изменение PK, которое по цепочке отстрелит триггеры ON UPDATE для дочерних таблиц.
24 янв 19, 13:00    [21793244]     Ответить | Цитировать Сообщить модератору
 Re: Конкурс идей про Firebird  [new]
Симонов Денис
Member

Откуда: Рязань
Сообщений: 10304
rdb_dev,

ну это уже откровенная чушь пошла. Смотри
1. На мастер таблицу триггеров можно написать скоко хошь
2. Триггеры можно вызвать только изменив что-то, это тебе не процедуры. Кстати всякие WITH LOCK никакие триггеры не дёргают к счастью
3. Передёргивать тысячи привязанных записей это зло. Проще такие вещи запретить концептуально
24 янв 19, 13:08    [21793258]     Ответить | Цитировать Сообщить модератору
 Re: Конкурс идей про Firebird  [new]
Фэйтл Эра
Member

Откуда:
Сообщений: 627
rdb_dev
Условимся, что триггер мастер таблицы ничего не знает о том, сколько дочерних таблиц у обрабатываемой им мастер таблицы и есть ли они вообще, да и не должен знать концептуально!


Меняешь определение "концептуальности", и всё.
Например: добавляешь новую "дочернюю" таблицу? Добавь к "родительской" таблице еще один триггер.

Хотя,
rdb_dev
Представь себе ситуацию, когда над БД работают несколько разработчиков - один создал мастер таблицу, дцать других разработчиков понаклепали к ней кучу дочерних таблиц и реализовали какую-то бизнес-логику. Как быть? Просить первого разработчика внести в триггер своей таблицы соответствующие изменения или другим разработчикам раздать номера триггеров на мастер таблицу, чтобы каждый из них сам написали свой триггер к мастер таблице? Вариант так себе...

- от бардака ничто не спасет.
24 янв 19, 13:08    [21793260]     Ответить | Цитировать Сообщить модератору
 Re: Конкурс идей про Firebird  [new]
Vlad F
Member

Откуда:
Сообщений: 1081
rdb_dev,

Я понял!!- сделай специальную "трубу" через отдельное поле и у мастера и у детали, соединенное каскадом на апдейт,
для именно такого "подергивания", и не морочь нам больше голову.))
P.S. Пиво, однозначно, мое.))
24 янв 19, 13:15    [21793274]     Ответить | Цитировать Сообщить модератору
 Re: Конкурс идей про Firebird  [new]
hvlad
Member

Откуда:
Сообщений: 10727
rdb_dev,

я уже говорил, что бизнес-логика на триггерах - ад ?
Всё ещё есть сомнения ?

Ты предлагаешь решение своей частной архитектурной проблемы вынести на общий системный уровень.
Вместо того, чтобы исправить своё прикладное решение.

Даже если пойти у тебя на поводу и добавить это в движок, это не спасёт тебя от десятков других
отрицательных последствий выбранной архитектуры.

А всё от того, что - см. выше
24 янв 19, 13:16    [21793276]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: Ctrl  назад   1 .. 19 20 21 22 23 [24] 25 26 27 28 .. 53   вперед  Ctrl
Все форумы / Firebird, InterBase Ответить