PaulWist
Как говорил т. Сталин: "Гинденбургов у меня для вас нет", те надо уметь работать с теми кто есть.

PaulWist
Разница только в том, то в моём понимании состояние данных должно всегда соотвествовать БЛ, в твоём понимании состояние данных может находится в рассогласованном состоянии с БЛ, те (запись в Алкоголе может отсутствовать, тем не менее бука "А" в продукте может находиться).

PaulWist
Дык, в том-то и дело, что ты НИКОГДА не сможешь вытащить ветвь дерева если оно зациклено не на родительский узел, а на один из дочерних узлов одной ветви

PaulWist
3. Ну вот, ты сам приводишь пример, (шапка и строки) рассогласованности данных с БЛ, с твоей точки зрения это норма для меня нет.

PaulWist
И это правильно, ты должен предусмотреть все возможные ситуации, а как ты это сделаешь - дело десятое.

PaulWist
Раньше я привел код триггеров для твоего примера с Продуктом и Алкоголем, ничего там сверх естественного нет, обычный код, правда требующий аккуратности в написании и понимании как работает триггер, то что не все так делают, ну это их право.

Igor Korolyov

PaulWist
Разница только в том, то в моём понимании состояние данных должно всегда соотвествовать БЛ, в твоём понимании состояние данных может находится в рассогласованном состоянии с БЛ, те (запись в Алкоголе может отсутствовать, тем не менее бука "А" в продукте может находиться).

Ещё раз по буквам. В моём понимании согласованность данных точно такая же как и в твоём.
Только обеспечивается она не "абы-когда" а лишь в согласованных снимках данных - грубо говоря на границе транзакций. И потому нарушение этой согласованности МЕЖДУ 2-мя insert-ами в рамках ОДНОЙ транзакции проблемой не является.
И да, контролировать всю БЛ может, естественно, лишь тот кто управляет транзакцией - да, это может быть ХП "для ввода алкоголя", и даже instead of триггер на специальную "алкогольную" вьюшку. Но никак не триггер на одну (или на обе) из "базовых" таблиц. Может это контролировать и сам клиент. Тем более что при использовании ORM это делает по сути системный код - прикладной разработчик НЕ ПИШЕТ эти insert-ы вручную!

Igor Korolyov

PaulWist
Дык, в том-то и дело, что ты НИКОГДА не сможешь вытащить ветвь дерева если оно зациклено не на родительский узел, а на один из дочерних узлов одной ветви

1) Смотря как вынимать.

Igor Korolyov

PaulWist
3. Ну вот, ты сам приводишь пример, (шапка и строки) рассогласованности данных с БЛ, с твоей точки зрения это норма для меня нет.

Ё-маё. Да как же НЕТ, когда ДА - когда ты сам страницу назад писал что у тебя строки "согласуются" (как глагол) с шапкой лишь при "утверждении/проведении" документа! Если ДО того как раз "поле в шапке" ни разу не соответствует "полям в строках"! И это "соответствие" НЕВОЗМОЖНО реализовать посредством триггеров. Никак! В принципе невозможно!

Igor Korolyov

PaulWist
И это правильно, ты должен предусмотреть все возможные ситуации, а как ты это сделаешь - дело десятое.

Зачем? Это в технологическом софте цена ошибки велика, а в рядовом бухгалтерско-учётном - мизерна. И удорожать софт в 3-4 раза совершенно нецелесообразно. При том что гарантировать на все 100% безошибочность ты всё равно не сможешь. А уж 2 девятки или 5 девяток в "надёжности" твоей софтины будет - это чисто вопрос цены - заплатят в 10 раз больше, ну будет на порядок больше малополезных проверок, и даже, возможно "дублирование логики" - т.е. 2-3 РАЗНЫЕ реализации алгоритма (выполненные разными командами разработчиков) с последующей сверкой результатов расчёта по каждому из них
Даже в софте для автопилотов встречаются ошибки, хотя уж там то каких только изощрённых методов повышения надёжности не применяют...

Igor Korolyov

PaulWist
Раньше я привел код триггеров для твоего примера с Продуктом и Алкоголем, ничего там сверх естественного нет, обычный код, правда требующий аккуратности в написании и понимании как работает триггер, то что не все так делают, ну это их право.

Ты привёл пример наглядно показывающий ущербность подхода (а другого там и быть не может - такова суть задачи). Для организации работы с таким образом "защищёнными" таблицами приходится ИСКАЖАТЬ логику работы ПО. Намеренно писать г*нокод - просто потому что система на вход ожидает именно г*но, чтобы его героически исправить и "сделать конфетку". А нормальные, корректные данные она не приемлет!
Грубо говоря, установив на дверь новейший электронный замок ты вынуждаешь пользователя либо выходить в окно, либо заходить в помещение "строго по трое"
Это по меньшей мере странно.

PaulWist
если выкинуть нафиг "этот дискриминатор", то код упроститься до нельзя, станет прозрачным и красивым

PaulWist
Как не вынимай, у тебя нет ссылок между корневым узлом и дочерними, те пойдя от дочернего (вверх), никогда не достигнешь корня (цикл), пойдя от корня (вниз), никогда не получишь всех потомков, поскольку на корень нет ссылки.

PaulWist
Ну-у-у, ты оделяй "мух от котлет", "проект данных" не является данными, тут ты совершенно прав, что для "проекта данных" нельзя построить никакой БЛ, ... у меня даже в мыслях не было, что ты говоришь о "проекте данных"

PaulWist
всё таки получить сообщение типа: "Заполните дату документа" куда приятнее, чем Field date dos'n accept null.

Igor Korolyov

PaulWist
если выкинуть нафиг "этот дискриминатор", то код упроститься до нельзя, станет прозрачным и красивым

Это лишь первый пришедший в голову "рабочий" пример имеющейся бизнес-связи между 2-мя таблицами. Можно подобрать и другой. К примеру связка таблиц "клиент - физлицо" с правилами "для физлица ИНН необязателен, для конторы - обязателен" или "для физлица статус не может быть vip, а статус gold могут иметь только совершеннолетние, несудимые граждане РФ".
Т.е. любое бизнес-правило затрагивающее поля из обеих таблиц мгновенно рушит всю твою систему "на триггерах".
...

create table People (ID int, Status_ID int, dDateBirth date )

create trigger IU_People on People
after insert, Update
as
begin
-- проверяем на Vip статус
if exists(select 1 from Inserted People 
inner join Status 
on People.Status_ID = Status.ID
and Status.Name = 'Vip'
begin
-- генерим ошибку, "Для физ. лица запрещен статус VIP"
end
-- Проверяем на возраст и судимость
if exists(select 1 from Inserted People 
inner join Status 
on People.Status_ID = Status.ID
and Status.Name = 'Gold'
and (FunctionAge.IsOK = 0 or FunctionCourt.IsOK = 1)
outer apply FunctionAge(People.ID) -- возвращаем совершеннолетие = 1
outer apply FunctionCourt(People.ID) -- вычисляем судимость = 1
begin
-- генерим ошибку, "Для физ. лица запрещен статус GOLD", поскольку
либо возраст, либо судимость или то и другое.
end
end

Igor Korolyov

PaulWist
Как не вынимай, у тебя нет ссылок между корневым узлом и дочерними, те пойдя от дочернего (вверх), никогда не достигнешь корня (цикл), пойдя от корня (вниз), никогда не получишь всех потомков, поскольку на корень нет ссылки.

Что-то ты не договариваешь...
В твоём примере:
1) нет никакого "корня", поскольку имеется цикл (все элементы равноправны).
2) начав с любого его (цикла) элемента можно получить все остальные элементы - лишь бы "метод получения" не зацикливался.
Приведи пример (просто пары id/parent_id и требуемое "действие прохода по иерархии") с "неправильным" поведением. Да, ещё надо учитывать что в такой схеме можно интерпретировать связь как "направленную", или как ненаправленную (сравняв id и parent_id в "правах" - тут "классические" иерархические запросы уже не подойдут, т.к. 1-2 и 2-3 должны в таком случае заодно "интерпретироваться" и как 3-2 и 2-1). Т.е. грубо говоря для цепочки 1-2-3 нельзя "считая от корня 3" получить элементы 2 и 1 - если не объявить связи "ненаправленными" - но тогда это уже будет терминологически не "корень и ветви дерева", а просто "узлы и рёбра неориентированного графа"...

...

use tempdb       
      go      
            
      create table test       
      (      
          ID int not null Primary key,      
          Parent_ID int FOREIGN KEY        
          REFERENCES test(ID )       
      )      
            
            
      insert into test (ID, Parent_ID) values (1, null)      
      insert into test (ID, Parent_ID) values (2, 1)      
      insert into test (ID, Parent_ID) values (3, 2)      
            
      -- замыкаем дерево НА ПЕРВЫЙ дочерний узел, получается "кольцо"      
      update test set Parent_ID = 3      
      where ID = 2      
            
      select * from Test

Цитата:

ID, Parent_ID
1 , Null
2 , 3
3 , 2

Igor Korolyov

PaulWist
Ну-у-у, ты оделяй "мух от котлет", "проект данных" не является данными, тут ты совершенно прав, что для "проекта данных" нельзя построить никакой БЛ, ... у меня даже в мыслях не было, что ты говоришь о "проекте данных"

В БД нет никаких "проектов данных". Там есть таблицы, записи и поля с данными в оных
И если рассуждать типа "вот тут у нас данные, а тут не данные, потому я их не проверяю", то уж извини, но это даже ещё более "мусорный" вариант нежели мой пример с 2-мя последовательно выполняемыми insert-ами. У меня хотя бы этот "мусор" не видит никто вовне транзакции, а у тебя он всем доступен - и без "сакрального знания" о том что ежели state=0 то это мусор а ежели state=1 то "данные" - никак не обойтись
Заметь - я не говорю что так делать нельзя - это допустимое компромиссное решение в ряде случаев. Но тут вспоминается старинный анекдот:
- И эти люди запрещают мне ковырять пальцем в носу!
...

Igor Korolyov

PaulWist
всё таки получить сообщение типа: "Заполните дату документа" куда приятнее, чем Field date dos'n accept null.

Кстати, это обычно проверяют "чисто на клиенте", задолго до того как пошлют сию запись на сервер. И "долбить" сервер "глупыми" записями чисто для того чтобы получить "красивый" текст ошибки - я считаю это неразумно...

PaulWist
Э-э-э, брат, объясни мне, как ты заполняешь документ, когда часть данных на момент заполнения ещё неизвестна? ставишь наобум обязательные атрибуты, а потом по ним можно сделать отчет? как ты узнаешь что в этом доке всё правильно заполнено, а другом нет?

pasha_usue
На момент когда пользователь заносит документ, все неизвестные для этого пользователя определены. Если это не так, то сущность документа выделена некорректно.

pasha_usue
Другой вопрос, пользователь для себя может считать, что документ рано принимать к учёту, он с ним продолжает работать. Тогда да, тогда есть неизвестные, как для пользователя, так и для системы.

of63
Где-то выше было хорошее замечание, что неплоха бы возможность ввода неполного документа, типа "черновик". Тогда система должна позволять ввести вообще пустой документ, типа APPEND BLANK в фоксе. Но это наверное нарушает красоту проверяльщиков-триггеров ввода в БД, и тогда выходит, что ХП на стороне БД нельзя сделать заточенными на ввод только правильного документа, т.к. возможны "черновики"... (я хоть немного улавливаю нить спора?)

PaulWist
1. Ты это "пальцем покажи", про "клиент - физлицо", скрипт таблиц, а то не понял.
2. Поскольку ты скрипты таблиц не привёл и если правильно понял структуру данных, то код такой:

PaulWist
в чем для тебя загвоздка?

PaulWist
Обращаю внимание, что ветвь замыкается для ID = 2, те получаем:

Цитата:

ID, Parent_ID
1 , Null
2 , 3
3 , 2

как видишь цикл замкнулся на ID = 2, для него родителем стал ID = 3, для которого родителем опять является ID = 2.

PaulWist
Поэтому, как бы ты не исхитрялся пойдя от ID = 1 поучить записи с ID = 2, 3, получишь одну запись.
Или пойдя от ID = 2 или ID = 3 получишь две записи, НО никогда не дойдешь до ID = 1, поскольку связь родитель-дочка разорвана.

PaulWist
Э-э-э, брат, объясни мне, как ты заполняешь документ, когда часть данных на момент заполнения ещё неизвестна? ставишь наобум обязательные атрибуты, а потом по ним можно сделать отчет? как ты узнаешь что в этом доке всё правильно заполнено, а другом нет?

PaulWist
А если не ставишь/заносишь в таблицы обязательные атрибуты, то чем твои данные отличаются от моих?

PaulWist
У меня то есть признак при stаtus = 0 я их не проверяю (не заношу в связанные таблицы, игнорирую почти всегда при отчетах), а при status = 1 проходит полный цикл БЛ, ... более того такие данные (ststus = 1) нельзя уже удалить опять же по БЛ и эту БЛ обеспечивают триггеры, констренты.

PaulWist
Не совсем, я уже приводил пример доступного лимита, когда договорились, что купят на 100р, а вот что конкретно и по какой цена ещё неизвестно.

PaulWist
Или принимают работника, с собой у него сейчас нет , например дипломов о курсах повышения квалификации, их можно внести "потом".

PaulWist

pasha_usue
На момент когда пользователь заносит документ, все неизвестные для этого пользователя определены. Если это не так, то сущность документа выделена некорректно.

Не совсем, я уже приводил пример доступного лимита, когда договорились, что купят на 100р, а вот что конкретно и по какой цена ещё неизвестно.

PaulWist
Или принимают работника, с собой у него сейчас нет , например дипломов о курсах повышения квалификации, их можно внести "потом".

of63
() У меня это пометка договора "черновик", или "договор заключен, но еще не жействует". Кстати бывает важно, когда именно клиент заключил жоговор, но не подтвердил. Может наличие поля "состояние записи" (например: черновик/действует/закончено) поможет?

Simple777
Видимо, не "дата составления", а "дата подписания" (дата регистрации)?

of63
возможность ввода неполного документа, типа "черновик". Тогда система должна позволять ввести вообще пустой документ, типа APPEND BLANK в фоксе. Но это наверное нарушает красоту проверяльщиков-триггеров ввода в БД, и тогда выходит, что ХП на стороне БД нельзя сделать заточенными на ввод только правильного документа, т.к. возможны "черновики"

pasha_usue

PaulWist

pasha_usue
На момент когда пользователь заносит документ, все неизвестные для этого пользователя определены. Если это не так, то сущность документа выделена некорректно.

Не совсем, я уже приводил пример доступного лимита, когда договорились, что купят на 100р, а вот что конкретно и по какой цена ещё неизвестно.

Это о чём я и говорил. Сущность документа в бизнес-процессе выделена неверно. Должен быть документ лимит-закупа (проект закупа), который может иметь расшифровку, а может не иметь. На этом документе участники процесса обговаривают, сколько денег готовы потратить. А потом происходит хозяйственная операция фактического закупа, для которой основанием может являться выделенный лимит. Или несколько таких операций.

pasha_usue

PaulWist
Или принимают работника, с собой у него сейчас нет , например дипломов о курсах повышения квалификации, их можно внести "потом".

Это не обязательная информация для кадрового учёта. Иногда требуется знать дату подтверждения квалификации и разрядности. Во всех остальных случаях, это зона ответственности ОК, а не программы.