Igor Korolyov

PaulWist
Т.е. с черным ящиком для конкретной БД может работать ЛЮБОЙ клиент (почти любой)

Точно так же как и с "сервисами". Ты используешь egruil или как там его... Курсы валют ЦБ? Данные из 1це или какой другой работающей у твоего клиента системы?
И тебе есть дело до того как оно там всё реализовано - на ХП, или в коде сервиса

Igor Korolyov
очему же тогда настаиваешь что только на ХП будет правильно (попутно отдавая доступ к БД абы кому, тогда как при работе слоя сервисов БД напрямую вообще никому не видна - не сможет злой/кривой клиент заDDoS-ить её, или пролезть через какую дыру в самой СУБД).

Igor Korolyov
При чём тут маркетинг? Это жизнь. Чем гибче решение, тем лучше.

PaulWist
но как всегда у этого плюса есть обратная сторона в качестве БД - набор таблиц

Да по барабану клиенту (челу который будет пользоваться ПО) набор таблиц там или не набор Ему надо чтобы адекватно работало и решало его задачи.
Чем был хорош фокс? Он позволял быстро и просто решить задачи юзера. Пока в течении нескольких лет на паскале писался интерфейс, на сях свой апп-сервер а на tsql логика в БД, кондовый фоксовик успевал уже сдать проект.

of63
DS ... Отношения польза/вред не прочуствовал, и не использую

Аспид

PaulWist
Ещё раз, такой подход МОЖЕТ существовать, только я его считаю НЕПРАВИЛЬНЫМ.

Так это все поняли)
Я и пытаюсь столкнуть. Ну почему?
Я повторюсь. Наверное фокс не лучший кандидат в средний слой.
Но софт (шарп) использующий ОРМ.
Ну удобнее там просто.
Речь не веду о целостности констрейнах.
Говорю о БЛ. О сложных процедурах.
К тому же, именно они подвержены наиболее частым изменениям.
Ну проще... есть объект, у него несколько методов. Все обычно. Легко находится, меняется,тестируется.
T-SQL как упоминали, совсем другой(
Да, и по мне, так для другого создан.

AndyNigmatec
З.Ы. в спор мэтров не вмешиваюсь - но тож интерестно - на чем порешат в итоге. У меня у самого все гораздо проще и тривиальнее - клиент-сервер, двухзвенка, никакого промежуточного слоя, все в локальной сети, логика размазана частью по коду, частью в БД в ХП - если честно делал как удобнее методом проб и ошибок, без глубокого погружения в теорию.

of63
Андрей, не слушай их (они сами друг друга, и себя уже не понимают), делай как посчитаешь нужным. А их споры... ну так... послушай... Доживешь до их/наших лет - поймешь )))

AndyNigmatec
У меня у самого все гораздо проще и тривиальнее - клиент-сервер, двухзвенка, никакого промежуточного слоя, все в локальной сети, логика размазана частью по коду, частью в БД в ХП - если честно делал как удобнее методом проб и ошибок, без глубокого погружения в теорию.

Аспид
каждый делает так, как ему удобнее.

Слюсарь делает так, как ему удобнее

Igor Korolyov

PaulWist
нужна защита от "дурака" или нет, я считаю, что нужна, более того на уровне БД, у тебя другой подход

Таки да. Предпочитаю всё ж работать не с дураками. Тем более что от "изобретательного" дурака защиту соорудить весьма сложно

Igor Korolyov

PaulWist
мои возражения только против того, что без существования записи в Алкоголе, буква "А" не должна существовать в таблице Продукт, поскольку это нарушает БЛ, вот и всё, в твоём же понимании Продукт МОЖЕТ существовать с буквой "А" без соответствующей записи в Алкоголе, что по постановке задачи НЕДОПУСТИМО.

Ты считаешь что целостность должна соблюдаться всегда. Я считаю что вполне допустимо чтобы она соблюдалась лишь для СОГЛАСОВАННОГО представления данных - а таковое имеет место в случае отсутствия незакоммиченных изменений. Если копнуть глубже и пойти "на принцип", то в твоей БД тоже вполне себе существует несогласованное состояние - это состояние в момент работы триггера - до его завершения. Просто его "не видит" никто кроме собственно триггера (а это как ты не крути не системный а вполне себе ПРИКЛАДНОЙ код - со всем вытекающим - повышенной возможностью ошибок или попросту "неучтённого" поведения), так же как в моём случае несогласованность не видит никто кроме ПО инициировавшего соответствующую последовательность операторов - да и то в рамках одной транзакции.

Igor Korolyov

PaulWist
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  
    
  ; with cte     
    (    
        ID,    
        Parent_ID,   
        cPath,   
        nLoop,  
        nLevel    
    )    
    as    
    (    
        select     
        ID,    
        Parent_ID,  
        '.' + CAST(test.ID AS varchar(max)) + '.' as cPath,    
        0 as nLoop,   
        1 as nLevel    
        from test where ID = 1    
        union all    
        select     
        test.ID,    
        test.Parent_ID,  
        cte.cPath + CAST(test.ID AS varchar(max)) + '.',    
        case  
            when cte.cPath like '%.' + cast(test.ID as varchar(max)) + '.%'  
            then cte.nLoop + 1  
            else cte.nLoop  
        end as nLoop ,  
        cte.nLevel + 1    
        from test  
        inner join cte on cte.ID = test.Parent_ID    
        where cte.nLoop < 1  
            
    )    
    select *  from cte where nLoop > 0  
    
  drop table test

Igor Korolyov

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

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

Igor Korolyov

PaulWist
Как писал Лес Пинтер: "Программных ошибок не существует в природе, а существуют ситуации для которых программист не предусмотрел проверку" - "золотые слова"!

Когда-то я тоже болел этим - в методе на 5 строк "полезного кода" писал ещё 50 строк "проверок параметров" - хорошо если в виде ASSERT, а не безусловного IF+ERROR
Потом, правда, отпустило

Igor Korolyov

PaulWist

Igor Korolyov
Да, а синтаксические ошибки в посылаемых на сервер командах ты тоже будешь триггерами исправлять

Ну да, для этого достаточно и в ХП и в ТРИГГЕРЕ

Не про них речь. Речь про клиента посылающего DML, или, раз ты его запретил напрочь, вызывающего твои мега-бронированные ХП. Вот описАлся он в названии ХП, или тип параметра не тот впихивает И, о боже мой, его программа весело падает на "ошибке от сервера" - виноват, конечно же сервер, а не слепой кодер прописавший number вместо date

Igor Korolyov

pasha_usue
Опять же, как расположить этот слой, абсолютно неважно.

Сию простую мыслЮ и пытаюсь донести уж сколько страниц. Но нет - ХП рулит, а то же самое в C# коде - ацтой

Владимир Максимов
При таком способе реализации на уровне триггеров задача неразрешима.

Именно. А по докУментам был спич ранее - но я как-то с настороженностью отношусь к "совсем убогим" записям в таблицах до момента "утверждения" - помню что ты именно так строишь проверки - до "финального нажатия кнопки" совершенно любой мусор позволяешь в записях держать... Это уже другая крайность IMHO.

Владимир Максимов
По поводу же переноса вообще всего кода на T-SQL лично мне это не кажется правильным всегда и везде. Имеет смысл только в случаях, когда база данных сама по себе является приложением. Т.е. работающие с ней системы - это своеобразные "терминалы" и не более того.

Таки да! А полноценное приложение на tsql (или pl/sql) - чур меня! Хотя таковые системы есть - и антикварный Oracle Forms и всякие APEX - веб-проги писанные средствами СУБД (там ваще "конструктор" - можно "кодить" без написания кода) Думаю и для MSSQL что-то подобное существует...

Владимир Максимов
Банально T-SQL неудобен с точки зрения разработки.

И я о том же! Для НЕКОТОРЫХ алгоритмов он нормален, но делать на нём ВСЁ - это явный перебор.