nnov wrote:
> По моему эта тема еще не обсуждалась, по крайней меря я ничего не нашел
> на здешнем форуме, а тема помоему весьма интересная
>
> Кто нибудь реально использовал такую модель данных как описанно в ссылке
> http://www.compress.ru/Common/Article/?619025C8DFD34BE59FC9313F34063E2B
>
> С первого взгляда удобно и универсально, но потом обнаруживаются
> проблемы при работе с таким количеством таблиц.
с каким "таким" количеством таблиц? их там всего ничего...

> У кого какие мнения по поводу модели Тенцера
ну, есть такая модель, юзаю нечто похожее... Юзается, ничо так...

>Эти топики я читал, там идет(или шло) обсуждение конкретных проблем
>реализации и Тенцер вспоминается как вариант решения проблемы, я же
>предлагаю остановится именно на этом варианте решения и глубже
>проанализировать плюсы и минусы такого решения.
А кому нужна конретно Тенцеровская реализация, кроме самого Тенцера? Там
ить описан подход, в обчим-то....
да и плюсы и минусы сам Тенцер по моему написал уже, прямо в статье...

>В каких случаях можно применять, на что обратить внимание, и вообще
>живучь такой механизм или нет.
применять - по вкусу, обращать внимания - на детали конкретной реализации.
Механизм - живучий, ломом не пришибешь...



--
-------------------------
There's no silver bullet!
Posted via ActualForum NNTP Server 1.3

nnov wrote:
> [quot locky]
> nnov wrote:
> >применять - по вкусу, обращать внимания - на детали конкретной реализации.
> С этим согласен, полностью, все объекты запихивать в такую схему
> я думаю будут сильные тормоза.
У нас на подобном принципе построены не только справочники, но и
документы. Быстродействие - приемлимое, особенно если брать еще бонусы
гибкости.

> >с каким "таким" количеством таблиц? их там всего ничего...
> имеется в виду то, что в принципе можно описать 2 таблицами
У меня хранилище данных описано 4 таблицами - термины, объекты,
значения, связи. А поверх этого - полтора десятка таблиц с описанием
метаданных, настроек, обработчиков и т.д.

>а в чем разница вашей реализации и модели Тенцера, мы ведь тут и
>тусуемся чтобы обсуждать реальные решения и обсуждать их плюсы и
>минусы, находя золотую середину
У меня используется кэширование ссылочных значений, к примеру. По
другому реализованы списковые аттрибуты, несколько другая идентификация
самих аттрибутов..

>
> Сейчас размышляю как быть с контролем вводимых данных, конкретно
> обязательность ввода данных конкретных атрибутов объекта, прихожу к
> выводу что здесь модель Тенцера очень слаба, или писать кучу надстроек
> и изобретать велосипед или никак... :(
дык у него модель для хранения данных. а для обработки... у меня,
опять-таки, реализовано хранение метаданных (обязательность, порядок,
именование параметров и проч.) а вся работа идет через т.н. машину
справочников - набор процедур, позволяющий
добавлять/удалять/изменять/выбирать экземпляр объекта.

--
-------------------------
There's no silver bullet!
Posted via ActualForum NNTP Server 1.3

nnov wrote:
> fraks
>
> ... контроль производится доп. звеном или на толстом клиенте.
>
>
>
> Это пожалуй самый большой минус, т.е. если хочешь воспользоваться такой
> схемой данных то приходиться тащить и толстого клиента, за собой а ради
> одного справочника как в моем случае это неоправданно долго и сложно.
> Или все делать так или не заморачиваться.
А сервер на что? При чем тут клиент? сервер должен заниматься такими делами.

>
> Я вообще, чем дольше изучаю и пробую эту модель прихожу к выводу, что
> она годна когда занимаешся тиражированием однотипных задач, где
> необходима быстрое получение какого нибудь (далеко не оптимального)
> результата.
Единожды созданая грамотная реализация машины справочников/документов
позволит применять их где попало (несколько преувеличено, но примерно
так). А оптимальное решение - штука слишком неоднозначная...

--
-------------------------
There's no silver bullet!
Posted via ActualForum NNTP Server 1.3

nnov wrote:
> locky
>
> У нас на подобном принципе построены не только справочники, но и
> документы. Быстродействие - приемлимое, особенно если брать еще бонусы
> гибкости.
>
>
>
> Я конечно еще не пробовал, реально, но мне кажется что именно документы
> т.е. объекты с которыми производиться много групповых операций и по
> которым троятся практически все отчеты в такой схеме будут давать
> большие тормоза. Да остаток по одному счету получаем с небольшой
> разницей по времени 1-2 секунды можно не принимать во внимание, но если
> делаем баланс по всем счетам то разница 1-2 секунды умножается на
> количество счетов и становиться значительной.
> Или я чего-то непонимаю.
я, конечно, пробовал... есть свои минусы, это да... зато повышается
скорость разработки. Да и унифицированно всё, например отчеты
настриваются автоматически - минимум вручную написанного кода.

>

> locky
>
> У меня хранилище данных описано 4 таблицами - термины, объекты,
> значения, связи. А поверх этого - полтора десятка таблиц с описанием
> метаданных, настроек, обработчиков и т.д.
>
>
> locky
>
> у меня, опять-таки, реализовано хранение метаданных (обязательность,
> порядок, именование параметров и проч.) а вся работа идет через т.н. машину
> справочников - набор процедур, позволяющий
> добавлять/удалять/изменять/выбирать экземпляр объекта.
>
>
>
> Вот это меня и смущает потому что в этом полтора десятке таблиц куче
> тригеров и процедур идет дублирование функционала СУБД на уровне
> объектов хранящихся в БД.
ну дык... таблиц - 2 десятка, процедур - десятка 3, триггеров нету.
И в целом это позволяет создать, к примеру, 600 справочников за 6
месяцев, причем людям, далёким от внутренностей справочников как таковых.


> По большому счету эта модель попытка реализации объектной модели на
> основе реляционной СУБД, по этому поводу сломано много копий и вобщем то
> не хочется заходить на новый круг, но минусы как я вижу начинаются
> именно от сюда...
> Ведь как просто, понятно и легко когда
> поставил not Null и готов контроль над обязательностью ввода
> соединил FK и значения будут только из связанной таблицы
> поставил UNIKUE и значения в поле уникальны.
> ну и т.д.
> А рассматриваемой схеме это все своими средствами за счет
> полтора десятка таблиц и д.р.
> Да красиво ложится объектная модель программы на базу, но по моему
> минусов гораздо больше чем плюсов.
прибавив к этим вот 600 справочников еще около 400 документов
(разработанных за те же полгода) прихожу к выводу, что традиционным
путём (НФ3 и прочая) было бы весьма напряжно всё это реализвать...



--
-------------------------
There's no silver bullet!
Posted via ActualForum NNTP Server 1.3

nnov wrote:
> locky
>
> я, конечно, пробовал... есть свои минусы, это да... зато повышается
> скорость разработки. Да и унифицированно всё, например отчеты
> настриваются автоматически - минимум вручную написанного кода.
>
>
> Унифицированность тоже палка о двух концах, да наверняка разработка
> будет быстрей, но как только я хочу реализовать какой либо справочник по
> особенному например древовидно, сразу проблемы...
нда? не вижу особых проблем, если честно...

>
> locky
>
> ну дык... таблиц - 2 десятка, процедур - десятка 3, триггеров нету.
> И в целом это позволяет создать, к примеру, 600 справочников за 6
> месяцев, причем людям, далёким от внутренностей справочников как таковых.
> прибавив к этим вот 600 справочников еще около 400 документов
> (разработанных за те же полгода) прихожу к выводу, что традиционным
> путём (НФ3 и прочая) было бы весьма напряжно всё это реализвать...
>
>
> Именно поэтому я и ищу способы как все это построить, сейчас обдумываю и
> рисую структуру достаточно большой информационной системы и прекрасно
> понимаю, что здесь необходимы другие подходы нежели чем в маленьких и
> средних. Но в такое решение нужно или что то другое неуверен.
> Ведь можно и так рассуждать:
> Да при традиционном подходе мне придется вместо 30 таблиц создать 300
> вместо 40 процедур написать 400. Но писать я их буду поэтапно, реализуя
> различные модули системы. Результаты по отдельным модулям появятся
> раньше, данные начнут набиваться раньше. А если реализовывать эту схему,
> пока не напишешь практически всю логику обработки никто ничего не сможет
> увидеть. И при обнаружении ошибки я думаю последствия могут быть более
> серьезными, а исправления более долгими...
не забудте также, что вместо одного интерфейса вам нужно будет создать,
скажем, 200, отладить какждый из них...
Тем паче, что яро создается достаточно быстро, а реализация самой логики
приложения - ну дык, у нас ядро позволяет на ходу регистрировать
дополнительные обработчики, необходимые системе.
К тому же ядро (теоретически) раз и навсегда отлаже и глюков там нет. А
если каждый раз, когда мне понадобится простой (или непростой)
справочник или документ, я буду разрабатывать структуры данных, писать
типовые процедуры доступа к данным, строить клиентскую часть... нафиг
нужно это?
На текущий момент для создания нового документа (справочника) кроме QA
мне не нужно ничего. При традиционном подходе нужен будет еще и Delphi
(С++, VB - по вкусу).


--
-------------------------
There's no silver bullet!
Posted via ActualForum NNTP Server 1.3

2Urry
да, типа того... полновесная (почти что) и полностью по
"Модифицированной Модели Тенцера". Точнее, как написал уже Михаил Бор
"Независимо от..." и т.д.
quot - тяжко, пишу то через громптицу...

>Недостатки такой схемы очевидны - декларативная целостность здесь
>отсутствует. Всё на усмотрение клиентской программы. Это вряд ли
>подходит для корпоративных систем. Про права доступа я и говорю - здесь
>они бессмысенны.
на физическом уровне - всё ок, а вот на логическом... запросто вместо
склада можно сослаться на единицу измерения :-)
Поэтому модификация данных происходит исключительно через серверный API
справочников.
А насчет прав - они реализуются значительно проще, чем при традиционной
схеме построения систем. Поскольку вся модификация централизована, то
достаточно в одной ключевой точке проверять права на возможность того
или иного действия.

Текущая максимальная ERP система - порядка 10 гектар, 100 юзеров,
2хКсеон 3, 4 RAM, 130К документов, 141К справочников. Жалобы редки.
Не ERP - 250 гектар, 70 юзеров, 2хКсеон 3, 8 RAM, 530К справочников,3М
документов (документы частично в форме Тенцера). Но там сильная мешанина
- от 1-й до 5-й НФ.


--
-------------------------
There's no silver bullet!
Posted via ActualForum NNTP Server 1.3

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

--
-------------------------
There's no silver bullet!
Posted via ActualForum NNTP Server 1.3