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

Откуда: с болот
Сообщений: 3812
Симонов Денис
1. На мастер таблицу триггеров можно написать скоко хошь
Если разработчиков много, бардак с триггерами на мастер таблицу, обновляющими дочерние таблицы, обеспечен. Ко всему прочему, придется функционал триггеров выносить в ХП и затем уже дёргать эти ХП и из триггеров дочерних таблиц и из триггеров мастер таблицы.

Симонов Денис
2. Триггеры можно вызвать только изменив что-то, это тебе не процедуры. Кстати всякие WITH LOCK никакие триггеры не дёргают к счастью
Так я и предлагаю симуляцию изменения PK мастера->FK дочерних таблиц, но без реального изменения значения PK->FK, а только использовать функционал, срабатывающий на изменение PK мастера. Про WITH LOCK я уже всё написал 21791911.

Симонов Денис
3. Передёргивать тысячи привязанных записей это зло. Проще такие вещи запретить концептуально
Если необходима согласованность данных, то по любому дёргать - что так, что эдак.
24 янв 19, 13:22    [21793286]     Ответить | Цитировать Сообщить модератору
 Re: Конкурс идей про Firebird  [new]
rdb_dev
Member

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

Я понял!!- сделай специальную "трубу" через отдельное поле и у мастера и у детали, соединенное каскадом на апдейт,
для именно такого "подергивания", и не морочь нам больше голову.))
P.S. Пиво, однозначно, мое.))
Думаешь, этот костыль с навёртыванием сигнального поля лучше, эффективнее и проще? А как же 3NF и устранение чрезмерной избыточности? :) Не лучше ли в качестве "сигнального поля" сразу использовать PK?

P.S. Ну хоть кто-то понял, о чем я толкую...
24 янв 19, 13:26    [21793290]     Ответить | Цитировать Сообщить модератору
 Re: Конкурс идей про Firebird  [new]
hvlad
Member

Откуда:
Сообщений: 11578
rdb_dev
придется функционал триггеров выносить в ХП
Шаг к выздоровлению.
rdb_dev
затем уже дёргать эти ХП и из триггеров
Нет, безнадёжен...
24 янв 19, 13:31    [21793295]     Ответить | Цитировать Сообщить модератору
 Re: Конкурс идей про Firebird  [new]
Симонов Денис
Member

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

ну если ты такой любитель триггеров и вообще странных извращённых решений. Напиши себе универсальный триггер на мастер таблицу, который сползает в системные таблицы, вытащит все зависимые таблицы и сделает для них холостой апдейт.
24 янв 19, 13:36    [21793303]     Ответить | Цитировать Сообщить модератору
 Re: Конкурс идей про Firebird  [new]
rdb_dev
Member

Откуда: с болот
Сообщений: 3812
hvlad
rdb_dev,

я уже говорил, что бизнес-логика на триггерах - ад ?
Всё ещё есть сомнения ?
То есть бизнес-логика на ХП с инициацией с клиента лучше? А как же согласованность и непротиворечивость данных в БД независимо от логики клиента? Что-то у меня это не укладывается в голове, в разрезе современных СУБД.

hvlad
Ты предлагаешь решение своей частной архитектурной проблемы вынести на общий системный уровень.
Вместо того, чтобы исправить своё прикладное решение.
Это не решение частной архитектурной проблемы, а концептуальное предложение, подразумевающее, что мастер таблица и её триггеры не обязаны знать, что там прикручено сверху и прикручено ли вообще (дочерние таблицы).

hvlad
Даже если пойти у тебя на поводу и добавить это в движок, это не спасёт тебя от десятков других
отрицательных последствий выбранной архитектуры.
Не надо идти у меня на поводу!
Я, с горем пополам, вполне переживу без этой фичи, но если разработчики сочтут её нелишней и реализуют, то это, ИМХО, поспособствует созданию более стройных архитектур БД, в которых необходимо использовать подобных подход.
24 янв 19, 13:36    [21793305]     Ответить | Цитировать Сообщить модератору
 Re: Конкурс идей про Firebird  [new]
Симонов Денис
Member

Откуда: Рязань
Сообщений: 11118
rdb_dev
То есть бизнес-логика на ХП с инициацией с клиента лучше? А как же согласованность и непротиворечивость данных в БД независимо от логики клиента?


для этого привилегии придумали. Ты можешь вообще запретить прямое изменение таблиц для не ДБА, только через ХП
24 янв 19, 13:41    [21793311]     Ответить | Цитировать Сообщить модератору
 Re: Конкурс идей про Firebird  [new]
rdb_dev
Member

Откуда: с болот
Сообщений: 3812
 		Симонов Денис, я устал объяснять...
24 янв 19, 13:44    [21793314]     Ответить | Цитировать Сообщить модератору
 Re: Конкурс идей про Firebird  [new]
Vlad F
Member

Откуда:
Сообщений: 1459
rdb_dev
Думаешь, этот костыль с навёртыванием сигнального поля лучше, эффективнее и проще? А как же 3NF и устранение чрезмерной избыточности? :) Не лучше ли в качестве "сигнального поля" сразу использовать PK?

Много лучше. Ибо оверхеда почти никакого нет (поле м.б. простейшим Char(1) и всегда иметь значение Null),
а самое главное, оно оционально больше ничего не затрагивает. Первоначальный архитектор сразу предусматривает
его в создаваемом мастере, а все последующие проектировщики всевозможных деталей при необходимости мигрируют
его также в них и охватывают каскадом. И все, проблема решена и никаких искусственных телодвижений в движке.
И в чем тут нарушение нормальных форм, не понимаю. Поясни хоть какой именно.
P.S. Ну хоть кто-то понял, о чем я толкую...

Ну, дык, какой рассказчик, такое и понимание..
24 янв 19, 13:47    [21793321]     Ответить | Цитировать Сообщить модератору
 Re: Конкурс идей про Firebird  [new]
rdb_dev
Member

Откуда: с болот
Сообщений: 3812
Vlad F
rdb_dev
Думаешь, этот костыль с навёртыванием сигнального поля лучше, эффективнее и проще? А как же 3NF и устранение чрезмерной избыточности? :) Не лучше ли в качестве "сигнального поля" сразу использовать PK?
Много лучше. Ибо оверхеда почти никакого нет (поле м.б. простейшим Char(1) и всегда иметь значение Null),
а самое главное, оно оционально больше ничего не затрагивает. Первоначальный архитектор сразу предусматривает
его в создаваемом мастере, а все последующие проектировщики всевозможных деталей при необходимости мигрируют
его также в них и охватывают каскадом. И все, проблема решена и никаких искусственных телодвижений в движке.
И в чем тут нарушение нормальных форм, не понимаю. Поясни хоть какой именно.
Так и сделано, но мне этот подход не импонирует.

Vlad F
rdb_dev
P.S. Ну хоть кто-то понял, о чем я толкую...

Ну, дык, какой рассказчик, такое и понимание..
Создается впечатление, что никто и никогда не разбивал БД на функционально независимые снизу вверх блоки. К примеру, я предпочитаю проверять работу бизнес-логики БД непосредственно из IBExpert просто меняя значение поля в таблице и проверяя, как это изменение повлияло на зависимые данные - на согласованность.
24 янв 19, 13:57    [21793337]     Ответить | Цитировать Сообщить модератору
 Re: Конкурс идей про Firebird  [new]
Симонов Денис
Member

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

ага, а потом надо какой-то апдейт сделать вне этой логики и побежал выключать триггеры.
Нет уж спасибо. Есть одна система доставшаяся по наследству с триггерной логикой на Оракуле. Там чёрт ногу сломит.
Поменял что-то а оно где то в триггерах что-то передёрнуло на что ты вообще не рассчитывал.
24 янв 19, 14:00    [21793342]     Ответить | Цитировать Сообщить модератору
 Re: Конкурс идей про Firebird  [new]
rdb_dev
Member

Откуда: с болот
Сообщений: 3812
Симонов Денис
rdb_dev,

ага, а потом надо какой-то апдейт сделать вне этой логики и побежал выключать триггеры.
Нет уж спасибо. Есть одна система доставшаяся по наследству с триггерной логикой на Оракуле. Там чёрт ногу сломит.
Поменял что-то а оно где то в триггерах что-то передёрнуло на что ты вообще не рассчитывал.
При подходе к проектированию БД, предусматривающему независимые снизу вверх блоки с вырожденным функционалом, все "апдейты" сводятся либо к расширению функционала путём добавления новых элементов не влезая в то, что уже работает, либо к изменению данных в условиях существующей в БД бизнес-логики.
24 янв 19, 14:10    [21793358]     Ответить | Цитировать Сообщить модератору
 Re: Конкурс идей про Firebird  [new]
hvlad
Member

Откуда:
Сообщений: 11578
rdb_dev
То есть бизнес-логика на ХП с инициацией с клиента лучше?
Значительно лучше.
Лучше пишется.
Лучше сопровождается.
Лучше анализируется.
Лучше контролирует связность подсистем\слоёв.
Не создаёт бардак в виде косвенных, никому не известных зависимостей.
Не делает из системы жёстко связанную головоломку.
Рекурсия из вызовов триггеров - то ещё удовольствие.
...ещё 100500 разных лучше...


rdb_dev
А как же согласованность и непротиворечивость данных в БД независимо от логики клиента
Не разрешай клиенту нарушать разработанный интерфейс взаимодействия с БД.

rdb_dev
Это не решение частной архитектурной проблемы
Именно частной и именно проблемы.
rdb_dev
а концептуальное предложение, подразумевающее, что мастер таблица и её триггеры не обязаны знать, что там прикручено сверху и прикручено ли вообще (дочерние таблицы).
Логика на процедурах вылечит тебя и от этого тоже.
И от того страшного дня, когда по изменению спец поля в мастере нужно будет что-то сделать не только в дочерних таблицах (или не во всех) - и триггерная логика пойдёт лесом в сад.
И процедурной логике, кстати, тоже не нужно знать что и где прикручено.
Способ "прикручивания" - часть прикладной архитектуры, от этого не уйти.
24 янв 19, 14:12    [21793362]     Ответить | Цитировать Сообщить модератору
 Re: Конкурс идей про Firebird  [new]
Dimitry Sibiryakov
Member

Откуда:
Сообщений: 54850
rdb_dev
Во-вторых - ты уверен, что правильно понимаешь 3NF?
В каком месте примера ниже денормализация? Все неключевые атрибуты, кроме штампа времени,
объединены в уникальную комбинацию, обеспечивающую условие "неключевые атрибуты"<=>"ключ",
что и является условием 3NF

Один из нас путает третью НФ со второй. В любом случае дублирование информации мастера с
деталях и наоборот есть денормализация.

Posted via ActualForum NNTP Server 1.5
24 янв 19, 14:12    [21793364]     Ответить | Цитировать Сообщить модератору
 Re: Конкурс идей про Firebird  [new]
rdb_dev
Member

Откуда: с болот
Сообщений: 3812
Dimitry Sibiryakov
В любом случае дублирование информации мастера с
деталях и наоборот есть денормализация.
Вот именно!
Поэтому я и не хочу тащить опорное поле из мастер таблицы в дочерние, так как это приводит к избыточности (денормализации), но, при этом, наступаю на грабли возможной несогласованности при изменении опорного поля в мастере. Вопрос, конечно, решаемый с помощью существующего функционала, как минимум, тремя способами, но все эти способы мне не очень нравятся и это моё "не очень нравятся", по всей видимости, теперь исключительно моя проблема. :)
24 янв 19, 14:24    [21793378]     Ответить | Цитировать Сообщить модератору
 Re: Конкурс идей про Firebird  [new]
Фэйтл Эра
Member

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

ну ты хоть приведи пример, что ты за данные в деталях формируешь "на основе мастера".
24 янв 19, 14:28    [21793381]     Ответить | Цитировать Сообщить модератору
 Re: Конкурс идей про Firebird  [new]
rdb_dev
Member

Откуда: с болот
Сообщений: 3812
hvlad
rdb_dev
То есть бизнес-логика на ХП с инициацией с клиента лучше?
Значительно лучше.
Лучше пишется.
Лучше сопровождается.
Лучше анализируется.
Лучше контролирует связность подсистем\слоёв.
Не создаёт бардак в виде косвенных, никому не известных зависимостей.
Не делает из системы жёстко связанную головоломку.
Рекурсия из вызовов триггеров - то ещё удовольствие.
...ещё 100500 разных лучше...
Ты перечислил то, за что я люблю ассемблер и недолюбливаю C++ - за неоднозначность поведения экземпляров классов, которые писал не ты. :) Почему бы тогда не обратится к старому, доброму формату DBF, обвязав реализованную на нём БД каким-нибудь API, написанным на Си, в котором будет реализована вся необходимая логика? И проблем из-за поломок БД меньше и бизнес-логика будет быстрее работать... ;)
24 янв 19, 14:34    [21793388]     Ответить | Цитировать Сообщить модератору
 Re: Конкурс идей про Firebird  [new]
Dimitry Sibiryakov
Member

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

Чо? В каком месте выборки будет несогласованность:
select мастер.опорное_поле, деталь.* from мастер, деталь

Posted via ActualForum NNTP Server 1.5
24 янв 19, 14:40    [21793392]     Ответить | Цитировать Сообщить модератору
 Re: Конкурс идей про Firebird  [new]
Симонов Денис
Member

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

не надо сравнивать огурцы с яблоками.
Про объектно-ориентированной программирование написано множество книжек, как и что надо проектировать чтобы не было мучительно больно. Ещё есть паттерны проектирования.

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

Откуда: с болот
Сообщений: 3812
Dimitry Sibiryakov
rdb_dev
я и не хочу тащить опорное поле из мастер таблицы в дочерние, так как это приводит к
избыточности (денормализации), но, при этом, наступаю на грабли возможной
несогласованности при изменении опорного поля в мастере

Чо? В каком месте выборки будет несогласованность:
select мастер.опорное_поле, деталь.* from мастер, деталь
Теперь представь, что деталь.*, это некие f(x), где "x" - "мастер.опорное_поле". Пока ты в транзакции, заблокировавшей изменение записи мастер таблицы с опорным полем, добавляешь детали - всё Ok, но как только ты закоммитил транзакцию и блокировка снялась, кто-то взял, да и поменял значение опорного поля. Что тогда? Тогда детали останутся f(OLD.x), что не есть "хорошо".
24 янв 19, 15:15    [21793469]     Ответить | Цитировать Сообщить модератору
 Re: Конкурс идей про Firebird  [new]
Vlad F
Member

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

А если все таки так (следи за руками), - первоначальный Создатель мастера создает, среди прочего,
первоначально пустую, SP БалансировкаВсевозможныхДеталей, помещает ее вызов в триггер на апдейт мастера
и пока все. Затем последующие безобразники создатели деталей, при такой необходимости, создают индивидуальные
экземпляры SP БалансировкаКонкретнойДетали и последовательно помещают их вызовы в упомянутую "абстрактную"
SP мастера, самого мастера и его самые ближние институты при этом уже никак не затрагивая. Ну и, типа, все, - все как
ты хотел, без затрагивания непосредственно мастера, без "денормализации", дешево, надежно и практично.))
24 янв 19, 15:19    [21793479]     Ответить | Цитировать Сообщить модератору
 Re: Конкурс идей про Firebird  [new]
rdb_dev
Member

Откуда: с болот
Сообщений: 3812
Симонов Денис
rdb_dev,
не надо сравнивать огурцы с яблоками.
Про объектно-ориентированной программирование написано множество книжек, как и что надо проектировать чтобы не было мучительно больно. Ещё есть паттерны проектирования.
Паттерны, это вообще "песня"!...
Паттерны прекрасно выводятся из самой концепции ООП, но один сообразительный чувак подумал - "почему бы не срубить на этом бабла?", взял, да и классифицировал все возможные варианты, опубликовав их. Молодец, чо!... Кто успел, того и денежки. :)
24 янв 19, 15:19    [21793483]     Ответить | Цитировать Сообщить модератору
 Re: Конкурс идей про Firebird  [new]
rdb_dev
Member

Откуда: с болот
Сообщений: 3812
 		Vlad F, это один из тех вариантов, который мне не нравиться. :) Нелаконично, что ли...
24 янв 19, 15:23    [21793487]     Ответить | Цитировать Сообщить модератору
 Re: Конкурс идей про Firebird  [new]
Dimitry Sibiryakov
Member

Откуда:
Сообщений: 54850
rdb_dev
Теперь представь, что деталь.*, это некие f(x), где "x" - "мастер.опорное_поле".

Ну как я и говорил, нарушение второй НФ, которая запрещает одним полям быть функцией
других полей. Выкидываешь их из деталь-таблицы, добавляешь f(x) в запрос и твои волосы
становятся обратно шелковистыми.

Posted via ActualForum NNTP Server 1.5
24 янв 19, 15:29    [21793505]     Ответить | Цитировать Сообщить модератору
 Re: Конкурс идей про Firebird  [new]
rdb_dev
Member

Откуда: с болот
Сообщений: 3812
 		Dimitry Sibiryakov, f(x) - условность, которая вообще может быть неким правилом для формирования графа самого "x". Если ты меняешь элемент графа, влекущего за собой проверку и/или пересчёт всех узлов графа, никакое вычисляемое поле тебе не поможет.
24 янв 19, 15:34    [21793514]     Ответить | Цитировать Сообщить модератору
 Re: Конкурс идей про Firebird  [new]
Vlad F
Member

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

У всякого, видишь ли, свой вкус: один любит арбуз, другой - свиной хрящик (с))))
Но не тащить же из за этого в привычный сервер всякие извраты.
Тем более, что в нем сейчас много чего более полезного и по факту стандартного пока нет.
24 янв 19, 15:34    [21793517]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: ←Ctrl  назад   1 .. 20 21 22 23 24 [25] 26 27 28 29 .. 59   вперед  Ctrl→
Все форумы / Firebird, InterBase Ответить