|
|
|
Модель данных по Тенцеру
|
|||
|---|---|---|---|
|
#18+
По моему эта тема еще не обсуждалась, по крайней меря я ничего не нашел на здешнем форуме, а тема помоему весьма интересная Кто нибудь реально использовал такую модель данных как описанно в ссылке http://www.compress.ru/Common/Article/?619025C8DFD34BE59FC9313F34063E2B С первого взгляда удобно и универсально, но потом обнаруживаются проблемы при работе с таким количеством таблиц. У кого какие мнения по поводу модели Тенцера ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.12.2005, 15:01 |
|
||
|
Модель данных по Тенцеру
|
|||
|---|---|---|---|
|
#18+
nnovПо моему эта тема еще не обсуждалась, по крайней меря я ничего не нашел на здешнем форуме, а тема помоему весьма интереснаяЭто по Вашему. Просто правильно формулируйте запросы ... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.12.2005, 15:39 |
|
||
|
Модель данных по Тенцеру
|
|||
|---|---|---|---|
|
#18+
Эти топики я читал, там идет(или шло) обсуждение конкретных проблем реализации и Тенцер вспоминается как вариант решения проблемы, я же предлагаю остановится именно на этом варианте решения и глубже проанализировать плюсы и минусы такого решения. В каких случаях можно применять, на что обратить внимание, и вообще живучь такой механизм или нет. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.12.2005, 15:52 |
|
||
|
Модель данных по Тенцеру
|
|||
|---|---|---|---|
|
#18+
nnov wrote: > По моему эта тема еще не обсуждалась, по крайней меря я ничего не нашел > на здешнем форуме, а тема помоему весьма интересная > > Кто нибудь реально использовал такую модель данных как описанно в ссылке > http://www.compress.ru/Common/Article/?619025C8DFD34BE59FC9313F34063E2B > > С первого взгляда удобно и универсально, но потом обнаруживаются > проблемы при работе с таким количеством таблиц. с каким "таким" количеством таблиц? их там всего ничего... > У кого какие мнения по поводу модели Тенцера ну, есть такая модель, юзаю нечто похожее... Юзается, ничо так... >Эти топики я читал, там идет(или шло) обсуждение конкретных проблем >реализации и Тенцер вспоминается как вариант решения проблемы, я же >предлагаю остановится именно на этом варианте решения и глубже >проанализировать плюсы и минусы такого решения. А кому нужна конретно Тенцеровская реализация, кроме самого Тенцера? Там ить описан подход, в обчим-то.... да и плюсы и минусы сам Тенцер по моему написал уже, прямо в статье... >В каких случаях можно применять, на что обратить внимание, и вообще >живучь такой механизм или нет. применять - по вкусу, обращать внимания - на детали конкретной реализации. Механизм - живучий, ломом не пришибешь... -- ------------------------- There's no silver bullet! Posted via ActualForum NNTP Server 1.3 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.12.2005, 18:06 |
|
||
|
Модель данных по Тенцеру
|
|||
|---|---|---|---|
|
#18+
[quot locky] nnov wrote: >применять - по вкусу, обращать внимания - на детали конкретной реализации. С этим согласен, полностью, все объекты запихивать в такую схему я думаю будут сильные тормоза. Я например сейчас занимаюсь системой заказа изделий и материалов в которой необходимо обеспечить возможность описывать самое разнообразное оборудование которое может потребоваться при постройке судна. Причем заранее описать все виды и типы оборудования не представляется возможным. Так вот именно справочник оборудования я думаю можно реализовать в этой модели, а дальнейшее движение - покупка, поступление на склад и в производство, по старой схеме. >с каким "таким" количеством таблиц? их там всего ничего... имеется в виду то, что в принципе можно описать 2 таблицами тот же справочник материалов и оборудования в данной схеме реализуется 2+2*количество типов полей = 10 в моем случае А из за этого трудней обрабатывать, как сделать запрос который выдает объект со всеми типами и значениями параметров, я например до сих пор немогу придумать нормального решения >ну, есть такая модель, юзаю нечто похожее... Юзается, ничо так... а в чем разница вашей реализации и модели Тенцера, мы ведь тут и тусуемся чтобы обсуждать реальные решения и обсуждать их плюсы и минусы, находя золотую середину Сейчас размышляю как быть с контролем вводимых данных, конкретно обязательность ввода данных конкретных атрибутов объекта, прихожу к выводу что здесь модель Тенцера очень слаба, или писать кучу надстроек и изобретать велосипед или никак... :( ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 20.12.2005, 10:04 |
|
||
|
Модель данных по Тенцеру
|
|||
|---|---|---|---|
|
#18+
nnovСейчас размышляю как быть с контролем вводимых данных, конкретно обязательность ввода данных конкретных атрибутов объекта, прихожу к выводу что здесь модель Тенцера очень слаба, или писать кучу надстроек и изобретать велосипед или никак... :( Так этот вывод у Тенцера в статье черным по белому написан. ;) Эта модель предполагает что тут данные только хранятся а весь контроль производится доп. звеном или на толстом клиенте. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 20.12.2005, 10:22 |
|
||
|
Модель данных по Тенцеру
|
|||
|---|---|---|---|
|
#18+
fraks ... контроль производится доп. звеном или на толстом клиенте. Это пожалуй самый большой минус, т.е. если хочешь воспользоваться такой схемой данных то приходиться тащить и толстого клиента, за собой а ради одного справочника как в моем случае это неоправданно долго и сложно. Или все делать так или не заморачиваться. Я вообще, чем дольше изучаю и пробую эту модель прихожу к выводу, что она годна когда занимаешся тиражированием однотипных задач, где необходима быстрое получение какого нибудь (далеко не оптимального) результата. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 20.12.2005, 11:36 |
|
||
|
Модель данных по Тенцеру
|
|||
|---|---|---|---|
|
#18+
nnov wrote: > [quot locky] > nnov wrote: > >применять - по вкусу, обращать внимания - на детали конкретной реализации. > С этим согласен, полностью, все объекты запихивать в такую схему > я думаю будут сильные тормоза. У нас на подобном принципе построены не только справочники, но и документы. Быстродействие - приемлимое, особенно если брать еще бонусы гибкости. > >с каким "таким" количеством таблиц? их там всего ничего... > имеется в виду то, что в принципе можно описать 2 таблицами У меня хранилище данных описано 4 таблицами - термины, объекты, значения, связи. А поверх этого - полтора десятка таблиц с описанием метаданных, настроек, обработчиков и т.д. >а в чем разница вашей реализации и модели Тенцера, мы ведь тут и >тусуемся чтобы обсуждать реальные решения и обсуждать их плюсы и >минусы, находя золотую середину У меня используется кэширование ссылочных значений, к примеру. По другому реализованы списковые аттрибуты, несколько другая идентификация самих аттрибутов.. > > Сейчас размышляю как быть с контролем вводимых данных, конкретно > обязательность ввода данных конкретных атрибутов объекта, прихожу к > выводу что здесь модель Тенцера очень слаба, или писать кучу надстроек > и изобретать велосипед или никак... :( дык у него модель для хранения данных. а для обработки... у меня, опять-таки, реализовано хранение метаданных (обязательность, порядок, именование параметров и проч.) а вся работа идет через т.н. машину справочников - набор процедур, позволяющий добавлять/удалять/изменять/выбирать экземпляр объекта. -- ------------------------- There's no silver bullet! Posted via ActualForum NNTP Server 1.3 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 20.12.2005, 11:37 |
|
||
|
Модель данных по Тенцеру
|
|||
|---|---|---|---|
|
#18+
nnov wrote: > fraks > > ... контроль производится доп. звеном или на толстом клиенте. > > > > Это пожалуй самый большой минус, т.е. если хочешь воспользоваться такой > схемой данных то приходиться тащить и толстого клиента, за собой а ради > одного справочника как в моем случае это неоправданно долго и сложно. > Или все делать так или не заморачиваться. А сервер на что? При чем тут клиент? сервер должен заниматься такими делами. > > Я вообще, чем дольше изучаю и пробую эту модель прихожу к выводу, что > она годна когда занимаешся тиражированием однотипных задач, где > необходима быстрое получение какого нибудь (далеко не оптимального) > результата. Единожды созданая грамотная реализация машины справочников/документов позволит применять их где попало (несколько преувеличено, но примерно так). А оптимальное решение - штука слишком неоднозначная... -- ------------------------- There's no silver bullet! Posted via ActualForum NNTP Server 1.3 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 20.12.2005, 11:40 |
|
||
|
Модель данных по Тенцеру
|
|||
|---|---|---|---|
|
#18+
locky У нас на подобном принципе построены не только справочники, но и документы. Быстродействие - приемлимое, особенно если брать еще бонусы гибкости. Я конечно еще не пробовал, реально, но мне кажется что именно документы т.е. объекты с которыми производиться много групповых операций и по которым троятся практически все отчеты в такой схеме будут давать большие тормоза. Да остаток по одному счету получаем с небольшой разницей по времени 1-2 секунды можно не принимать во внимание, но если делаем баланс по всем счетам то разница 1-2 секунды умножается на количество счетов и становиться значительной. Или я чего-то непонимаю. locky У меня хранилище данных описано 4 таблицами - термины, объекты, значения, связи. А поверх этого - полтора десятка таблиц с описанием метаданных, настроек, обработчиков и т.д. locky у меня, опять-таки, реализовано хранение метаданных (обязательность, порядок, именование параметров и проч.) а вся работа идет через т.н. машину справочников - набор процедур, позволяющий добавлять/удалять/изменять/выбирать экземпляр объекта. Вот это меня и смущает потому что в этом полтора десятке таблиц куче тригеров и процедур идет дублирование функционала СУБД на уровне объектов хранящихся в БД. По большому счету эта модель попытка реализации объектной модели на основе реляционной СУБД, по этому поводу сломано много копий и вобщем то не хочется заходить на новый круг, но минусы как я вижу начинаются именно от сюда... Ведь как просто, понятно и легко когда поставил not Null и готов контроль над обязательностью ввода соединил FK и значения будут только из связанной таблицы поставил UNIKUE и значения в поле уникальны. ну и т.д. А рассматриваемой схеме это все своими средствами за счет полтора десятка таблиц и д.р. Да красиво ложится объектная модель программы на базу, но по моему минусов гораздо больше чем плюсов. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 20.12.2005, 12:34 |
|
||
|
Модель данных по Тенцеру
|
|||
|---|---|---|---|
|
#18+
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 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 20.12.2005, 12:41 |
|
||
|
Модель данных по Тенцеру
|
|||
|---|---|---|---|
|
#18+
locky я, конечно, пробовал... есть свои минусы, это да... зато повышается скорость разработки. Да и унифицированно всё, например отчеты настриваются автоматически - минимум вручную написанного кода. Унифицированность тоже палка о двух концах, да наверняка разработка будет быстрей, но как только я хочу реализовать какой либо справочник по особенному например древовидно, сразу проблемы... locky ну дык... таблиц - 2 десятка, процедур - десятка 3, триггеров нету. И в целом это позволяет создать, к примеру, 600 справочников за 6 месяцев, причем людям, далёким от внутренностей справочников как таковых. прибавив к этим вот 600 справочников еще около 400 документов (разработанных за те же полгода) прихожу к выводу, что традиционным путём (НФ3 и прочая) было бы весьма напряжно всё это реализвать... Именно поэтому я и ищу способы как все это построить, сейчас обдумываю и рисую структуру достаточно большой информационной системы и прекрасно понимаю, что здесь необходимы другие подходы нежели чем в маленьких и средних. Но в такое решение нужно или что то другое неуверен. Ведь можно и так рассуждать: Да при традиционном подходе мне придется вместо 30 таблиц создать 300 вместо 40 процедур написать 400. Но писать я их буду поэтапно, реализуя различные модули системы. Результаты по отдельным модулям появятся раньше, данные начнут набиваться раньше. А если реализовывать эту схему, пока не напишешь практически всю логику обработки никто ничего не сможет увидеть. И при обнаружении ошибки я думаю последствия могут быть более серьезными, а исправления более долгими... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 20.12.2005, 13:14 |
|
||
|
Модель данных по Тенцеру
|
|||
|---|---|---|---|
|
#18+
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 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 20.12.2005, 13:25 |
|
||
|
Модель данных по Тенцеру
|
|||
|---|---|---|---|
|
#18+
to locky: авторприбавив к этим вот 600 справочников еще около 400 документов А куда такое количество справочников и документов? У вас что - полновесная ERP система построеная ПОЛНОСТЬЮ на "модели Тенцера"?? 8O P.S. большая просьба - пользуйтесь пожалуйста тэгом "quote": очень тяжело читать Ваши посты - все сливается. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 20.12.2005, 14:03 |
|
||
|
Модель данных по Тенцеру
|
|||
|---|---|---|---|
|
#18+
Насчет плохого быстродействия в базе, спроектированной по теории Тенцера - сказки. Кто-нибудь проверял это? Или это ваши предположения? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 20.12.2005, 14:08 |
|
||
|
Модель данных по Тенцеру
|
|||
|---|---|---|---|
|
#18+
Old NickНасчет плохого быстродействия в базе, спроектированной по теории Тенцера - сказки. Кто-нибудь проверял это? Или это ваши предположения? Сам конечно не проверял, для этого надо реализовать эту модель да еще данные в нее накачать, что тоже к стати гораздо труднее по сравнению с традиционными структурами Пока основываюсь на статье Змеева и Моисеева, если интересно то введите в Google --> "Модификация Модели Тенцера" попадете на этот документ ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 20.12.2005, 14:49 |
|
||
|
Модель данных по Тенцеру
|
|||
|---|---|---|---|
|
#18+
Привет всем! Мы незавсимо от автора пробовали такую модель данных. Причем каждый тип хранился в своей примитивной таблице, скажем varchar(10) в одной а varchar(20) в сдедующей, int в своей и так далее. Прикладные таблицы (справочник товаров документы) - это view. В такую схему пергнали реальные данные около 500 тыс записей справочника товаров и 900 тыс доументов. Оказалось, что работа с view (выборка) существенно зависит от того как писать соединение примитивных таблиц (хранящих один тип) в о View. Если написать правильно, то выборка существено ускоряется. Это понятно все примитивные таблицы индексированны. Недостатки такой схемы очевидны - декларативная целостность здесь отсутствует. Всё на усмотрение клиентской программы. Это вряд ли подходит для корпоративных систем. Про права доступа я и говорю - здесь они бессмысенны. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 20.12.2005, 15:46 |
|
||
|
Модель данных по Тенцеру
|
|||
|---|---|---|---|
|
#18+
nnov Сам конечно не проверял, для этого надо реализовать эту модель да еще данные в нее накачать, что тоже к стати гораздо труднее по сравнению с традиционными структурами У модели Тенцера есть хороший аргумент - она реализована на практике. Несколько (много) лет назад ходил к нему на экскурсию. База была 7 гигов, под MS SQL. Более 100 активнынх клиентов, некоторое кол-во клиентов по выделенке 128кб, двухголовый Ксеон, серверная - для меня тогда все это выглядело как фантастика. Сейчас с аналогичным в одной комнате сижу ;) Но я отвлекся.. В общем при такой базе жалоб на недостаток быстродествия я не слышал. Собственно я туда и попал-то по той причине что усиленно объяснял окружающим что лучше нагрузить клиент и разгрузить сервер - ему и так не сладко, а клиент будучи написан правильно - с такой нагрузкой справляется. Вот и был приглашен на экскурсию - посмотреть на быстродействие. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 20.12.2005, 15:47 |
|
||
|
Модель данных по Тенцеру
|
|||
|---|---|---|---|
|
#18+
Михаил Бор Недостатки такой схемы очевидны - декларативная целостность здесь отсутствует. Всё на усмотрение клиентской программы. Это вряд ли подходит для корпоративных систем. Про права доступа я и говорю - здесь они бессмысенны. Вот и я о том же, красота решения и универсальность, в ущерб целостности, и гибкой системе прав. Думаю, что реализация грамотного отслеживания целостности данных и прав, а реализовывать как уже говорилось раньше надо все самому, может превзойти по трудоемкости стандарное решение с сотнями таблиц и клиентских интерфейсов... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 20.12.2005, 16:43 |
|
||
|
Модель данных по Тенцеру
|
|||
|---|---|---|---|
|
#18+
Привет всем! Ещё прибавление. С выходом в свет SQL 2005 всё что связно с со структурой типа "open schema" можно делать по другому и иметь для этого нужную "поддерждку" сервера!!! ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 20.12.2005, 17:33 |
|
||
|
Модель данных по Тенцеру
|
|||
|---|---|---|---|
|
#18+
Почитал статью. На объеме БД не доходящей до 100 МБ писать фразу о необходимости использования этой модели при "разработке сложных информационных систем" мне кажется немного лозунговой. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 20.12.2005, 18:39 |
|
||
|
Модель данных по Тенцеру
|
|||
|---|---|---|---|
|
#18+
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 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 20.12.2005, 19:07 |
|
||
|
Модель данных по Тенцеру
|
|||
|---|---|---|---|
|
#18+
Дополнительное преимущество такой модели состоит в том, что некоторые повседневые задачи становятся достаточно просто решаемые. Например, произвольная фильтрация по заранее неизвестному перечню полей. Или просмотр 2-х взаимосвязанных справочников. Да хотя бы выяснение: где же конкретно используется вот такая единица измерения? всё решается элементарно. А за счет унификации интерфейса значительно снижается время обучения пользователей. Хотя у унификации есть обратная сторона - некоторые задачи удобнее было бы решать иным способом, но чтобы не отходить от стандарта, решаем не самым удобным.... но такое достаточная редкость, можно мирится с этим. -- ------------------------- There's no silver bullet! Posted via ActualForum NNTP Server 1.3 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 20.12.2005, 19:21 |
|
||
|
Модель данных по Тенцеру
|
|||
|---|---|---|---|
|
#18+
Считаю, что наиболее целесообраным является гибридный подход, т.е. основные измерения разнесены по таблицам, а неосновные и дополнительные поля по Тецнеру. Работает быстро, быстрее чем по Тецнеру 100%, и оптимально для ведения консолидированных баз.... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 20.12.2005, 21:20 |
|
||
|
Модель данных по Тенцеру
|
|||
|---|---|---|---|
|
#18+
to locky: ИМХО представляется очень сомнительной целесообразность использования "модели Тенцера" (При чем тут кстати Тенцер? Такая архитектура известна со времен царя Гороха..) в Вашем случае. Большинство документов реализующих функционал бухучета/торговли/зарплаты и др. вполне свободно ложаться на стандартные "плоские" таблицы. Они-же не меняют свою структуру каждый день? Раз сформированые они работают 1-2 года до очередной переделки (до смены бизнес процессов/законодательства). Единственный плюс - скорость построения схемы хранения таких документов. Но это все равно изврат - просто попытка невелировать ущербность RAD средствами приложения. По крайней мере несколько раз видел подобное применение аналогичной архитектуры - и каждый раз основным мотивом применение ее была как раз ущербность среды разработки. Единственным реально необходимым применением данной архитектуры является использование быстроменяющихся объектов приложения. Это например классы "продукция", "материалы и комплектующие", "спецификация" и др. Мне очень интересно - каким RAD Вы пользуетесь и какова платформа разработанного Вами приложения. Я честно говоря в тупике - не могу понять цимус использования динамически меняющихся классов ВО ВСЕМ приложении. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 20.12.2005, 21:20 |
|
||
|
Модель данных по Тенцеру
|
|||
|---|---|---|---|
|
#18+
UrryMcAПри чем тут кстати Тенцер? Такая архитектура известна со времен царя Гороха..) Тенцер тут при том что реализовал такую схему и описал в своей статье. Говоря "по схеме Тенцера" имеют ввиду схему описанную в статье Анатолия Тенцера. Прикладная область у него - оптовая торговля медикаментами. Система автоматизирует не только товарные операции но и всю бухгалтерию. Я в свое время пытался реализовать такую схему но скис на сложности реализации клиента (делал в виде двухзвенки). ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.12.2005, 05:42 |
|
||
|
Модель данных по Тенцеру
|
|||
|---|---|---|---|
|
#18+
Скисать в таких вопросах ну никак нельзя, а то придется работать по части разгрузки медикаментов. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.12.2005, 09:23 |
|
||
|
Модель данных по Тенцеру
|
|||
|---|---|---|---|
|
#18+
Programmer_OrtodoxСкисать в таких вопросах ну никак нельзя, а то придется работать по части разгрузки медикаментов. Так я только в порядке эксперимента, пошшупать так сказать... Моя система для книжек сделана, чиста классически ;) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.12.2005, 10:46 |
|
||
|
Модель данных по Тенцеру
|
|||
|---|---|---|---|
|
#18+
2 UrryMcA] модели действительно лет 30 принципиальные преимущества: добавление новых \изменение стр-ры справочников делает (конечный) пользователь добавление новых \изменение стр-ры документов-операций делает (конечный) пользователь о других преимуществах (права доступа, интерфейс, контроль целостности и т.д.) уже говорили недостаток - большое число записей в таблицах и как следствие большой объем индексов - лечится памятью сервера ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.12.2005, 11:02 |
|
||
|
Модель данных по Тенцеру
|
|||
|---|---|---|---|
|
#18+
UrryMcA wrote: > to locky: > > ИМХО представляется очень сомнительной целесообразность использования > "модели Тенцера" (При чем тут кстати Тенцер? Такая архитектура известна > со времен царя Гороха..) в Вашем случае. в моем случае - в каком? первом/втором? А тенцер тут - токо как общая точка приложения - есть статья, которую все тут читали. потому и "Модель Тенцера". В аутглюке кста, где-то тоже поля вот так набираются. > > Большинство документов реализующих функционал бухучета/торговли/зарплаты > и др. вполне свободно ложаться на стандартные "плоские" таблицы. Да все они ложаться! Только оборотка по 40 типам документов выглядит в лудшем случае как 40 последовательных union all, и при каждом добавлении документа надо дописывать массу отчетов. Конечно, можно использовать журналы операций, но это - прямое дублирование информации. > > Они-же не меняют свою структуру каждый день? Раз сформированые они > работают 1-2 года до очередной переделки (до смены бизнес > процессов/законодательства). Нет, не меняют каждый день. Один раз в полгода - уже достаточно. > > Единственный плюс - скорость построения схемы хранения таких документов. > Но это все равно изврат - просто попытка невелировать ущербность RAD > средствами приложения. Огромный плюс! Снижается стоимость разработки - растёт зарплата. > > По крайней мере несколько раз видел подобное применение аналогичной > архитектуры - и каждый раз основным мотивом применение ее была как раз > ущербность среды разработки. Среда - что? Сиквел? Делфин? > > Мне очень интересно - каким RAD Вы пользуетесь и какова платформа > разработанного Вами приложения. Я честно говоря в тупике - не могу > понять цимус использования динамически меняющихся классов ВО ВСЕМ > приложении. Во первых, не "цимус", а "цимес" - не позорьте нас с Вами. По сущейству - MS SQL2K+Delphi 7.0+DevExpress. Классы не динамически меняются.... они единоразово настраиваются. И это есть плюс. -- ------------------------- There's no silver bullet! Posted via ActualForum NNTP Server 1.3 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.12.2005, 11:46 |
|
||
|
Модель данных по Тенцеру
|
|||
|---|---|---|---|
|
#18+
eav добавление новых \изменение: 1. стр-ры справочников делает (конечный) пользователь 2. стр-ры документов-операций делает (конечный) пользователь Как уже где-то здесь говорилось - свобода изменения структуры приложения пользователем почти всегда приводит к хаосу в учетной системе. ИМХО Бизнес-процессы на предприятиях россии и так находятся в жутком состоянии. А если дать еще и пользователю изменять в оперативном режиме схему документооборота/аналитики - будет совсем "вешалка". Согласен - в определенных случаях такая схема себя оправдывает. Но в своей практике я такого не встречал. Я например не могу себе такое представить, что без согласования хотя-бы с CIO/CFO пользователь мог изменить структуру документооборота/аналитику. В моем случае это неизбежно вызовет убытков на пару лимонов в месяц. (В худшем случае пишется служебная записка, а лучше - аналитик пишет документ с анализом возможных "косяков".) lockyКонечно, можно использовать журналы операций, но это - прямое дублирование информации. ?? Т.е. у Вас аналитические/синтетические отчеты строются по документам(по записям первичной информации)??? ИМХО - возможное решение, но не оптимальное в некоторых случаях. Встречал в своей практике и считаю такой вариант неприемлемым. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.12.2005, 18:21 |
|
||
|
Модель данных по Тенцеру
|
|||
|---|---|---|---|
|
#18+
UrryMcAКак уже где-то здесь говорилось - свобода изменения структуры приложения пользователем почти всегда приводит к хаосу в учетной системе. ИМХО Бизнес-процессы на предприятиях россии и так находятся в жутком состоянии. А если дать еще и пользователю изменять в оперативном режиме схему документооборота/аналитики - будет совсем "вешалка". Согласен - в определенных случаях такая схема себя оправдывает. Но в своей практике я такого не встречал. Я например не могу себе такое представить, что без согласования хотя-бы с CIO/CFO пользователь мог изменить структуру документооборота/аналитику. В моем случае это неизбежно вызовет убытков на пару лимонов в месяц. (В худшем случае пишется служебная записка, а лучше - аналитик пишет документ с анализом возможных "косяков".) Пользователь здесь в смысле "не программист". Как это в реальности происходит - с согласованием с CIO/CFO, без него, со служебной запиской/без - это их личные сексуальные проблемы. Главное чтобы это можно было делать без участия разработчика, возможно специально обученным администратором такой системы. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.12.2005, 19:08 |
|
||
|
Модель данных по Тенцеру
|
|||
|---|---|---|---|
|
#18+
Я таки понял в каких случаях схема "по Тенцеру" себя оправдывает - 1. Система должна просто "фиксить" результаты хоз деятельности предприятия. "Главное - учет" - доктрина такой архитектуры. Функционирование бизнес процессов предприятия поддерживается в основном организационными мерами и не отражено в Системе. 2. Имеется достаточное количество операторов, чтобы вводить данные в систему с постоянно увеличивающимся/изменяющимся количеством справочников/документов. 3. Быстрое построение отчетов не требуется. Схема наиболее оптимальна на предприятии с "посмертным" учетом - например крупные производственные предприятия "советского" типа, которые живут плановыми показателями предыдущего месяца. 4. Основной контингент операторов - достаточно квалифицированы, чтобы правильно заполнять документы/получать отчеты. Они работают на предприятии достаточно долго, чтобы знать ньюансы бизнес процессов. --- Очень логичным здесь выглядит как-раз построение отчетности на первичных данных ("от документа"). Поскольку нет возможности прописать процедуры, которые формируют регистры учетов "на лету" (документ вводит "пользователь"), то такой способ построения отчетов здесь - самый логический и я бы сказал гармоничный. Я кажется понял причины возникновения такой архитектуры. С учетом имеющихся ограничений - имеет право на реализацию. Учту на будущее. ;) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.12.2005, 20:24 |
|
||
|
Модель данных по Тенцеру
|
|||
|---|---|---|---|
|
#18+
2 UrryMcA Все наоборот Все нормальные системы учета/анализа построены именно так: набор документов определяет пользователь набор аналитик определяет пользователь проводки по этим документам и аналитикам настраивает пользователь БП настраивает пользователь отчеты запрограмированы заранее и строятся только по проводкам ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.12.2005, 11:36 |
|
||
|
Модель данных по Тенцеру
|
|||
|---|---|---|---|
|
#18+
eav набор документов определяет пользователь набор аналитик определяет пользователь проводки по этим документам и аналитикам настраивает пользователь БП настраивает пользователь отчеты запрограмированы заранее и строятся только по проводкам "Набор документов" - в смысле количество видов документов используемых конкретным пользователем настраивается без перепрограммирования БД? "набор аналитик" - в смысле количество и вид параметров документа настраивается без перепрограммирования БД? "проводки по этим документам и аналитикам" - в смысле содержание проводок формируемых по первичным документам настраивается без перепрограммирования БД? Если это так - то подобные возможности предоставляют практически все общедоступные учетные системы (которые построены совсем не "по Тенцеру") В таком случае применение "модели Тенцера" не имеет особых преимуществ при построении учетной системы. Не готов сейчас подробно обсуждать преимущества/недостатки предложеной архитектуры - это требует времени на дополнительный анализ, которого у меня нет. Хотя с удовольствием почитаю чужие мысли по этому поводу. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.12.2005, 12:26 |
|
||
|
Модель данных по Тенцеру
|
|||
|---|---|---|---|
|
#18+
UrryMcA "Набор документов" - в смысле количество видов документов используемых конкретным пользователем настраивается без перепрограммирования БД? "набор аналитик" - в смысле количество и вид параметров документа настраивается без перепрограммирования БД? "проводки по этим документам и аналитикам" - в смысле содержание проводок формируемых по первичным документам настраивается без перепрограммирования БД? Если это так - то подобные возможности предоставляют практически все общедоступные учетные системы (которые построены совсем не "по Тенцеру") Да, включая и проектирование экранных форм документов, разработку новых справочников (и их экранных форм) для аналитического учета и т.д. М.б. какие-то учетные системы это и позволяют (далеко не все), но с моделью EAV это делать проще. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.12.2005, 12:41 |
|
||
|
Модель данных по Тенцеру
|
|||
|---|---|---|---|
|
#18+
UrryMcA wrote: > Я таки понял в каких случаях схема "по Тенцеру" себя оправдывает - > > 1. Система должна просто "фиксить" результаты хоз деятельности поскипано... > предприятии достаточно долго, чтобы знать ньюансы бизнес процессов. > и причему тут организация бизнес процессов, квалификация пользователей, плановые показатели и проч. к модели данных? Модель Тенцера в 95% случаев прямо трансформируется в обычную 3НФ. когда мне приходит в голову сгененрировать диаграмму, я запускаю небольшой скрипт, который на основании модели Тенцера генерирует привычную БД в 3Нф (заодно и данные туда переливает). Я понимаю, когда имеются опасения насчет производительности - да, там не всё так гладко, хотя во многих случаях получается лучше, чем при 3НФ. Бывает, однако, что и голову приходится поломать... а пассаж насчет "Основной контингент операторов - достаточно квалифицированы, чтобы правильно заполнять документы/получать отчеты. Они работают на предприятии достаточно долго, чтобы знать ньюансы бизнес процессов." - довёл до нервного тика... какая пользователю разница, что лежит в глубине приложения? Пусть там хоть б-трив лежит, если в системе не предусмотрены проверки/схемы заполнения/схемы оформления и проч. - кака таки будет. ------------------------- There's no silver bullet! Posted via ActualForum NNTP Server 1.3 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.12.2005, 14:08 |
|
||
|
Модель данных по Тенцеру
|
|||
|---|---|---|---|
|
#18+
Это на самом деле уже оффтоп - но я просто отвечаю на Ваш вопрос, locky. Если есть желание поспорить каким боком модель данных/архитектура приложения могут повлиять на бизнес процессы - открывайте новый топик - там и поспорим. lockyи причем тут организация бизнес процессов? Модель данных определяет логику работы с системой и накладывает определенные ограничения на функционал. набор документов определяет пользователь набор аналитик определяет пользователь проводки по этим документам и аналитикам настраивает пользователь БП настраивает пользователь Поскольку функционал в данном случае определяется пользователем, а документ = часть бизнес процесса - делаю вывод, что причем. lockyкакая пользователю разница, что лежит в глубине приложения? Пусть там хоть б-трив лежит, если в системе не предусмотрены проверки/схемы заполнения/схемы оформления и проч. - кака таки будет. Механизмы валидации данных вводимых в Систему- вещь стандартная. Речь не о них. Любой класс Системы является так или иначе отображением бизнес-процессов предприятия на структуру Системы. Документы и справочники не существуют как вещь в себе, они организуют какую-то функцию. Я так понял - Вы утверждаете, что используя ограниченный инструменарий настроек документов/справочников Вы в состоянии адекватно реализовать систему реализующую бизнес процессы любого предприятия? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.12.2005, 16:32 |
|
||
|
Модель данных по Тенцеру
|
|||
|---|---|---|---|
|
#18+
UrryMcA wrote: > locky > и причем тут организация бизнес процессов? > > Модель данных определяет логику работы с системой и накладывает > определенные ограничения на функционал. да вы что!!!!!! То исть, в зависимости от того, как я храню данные, я могу или не могу провести некую операцию??? типа... если я веду бумажный учет, то поставить на забаланс при выдаче МНМА в эксплуатацию я могу (модель данных - складские карточки), а если я пытаюсь сделать то-же самое в Excel - то пол руки?? даже немного не так... карточки, эксель - не модель данных, всё таки... а! если я храню карточки в шкафах - то могу, а если храню карточки в тумбочках - то не могу??? > locky > какая пользователю разница, что > лежит в глубине приложения? Пусть там хоть б-трив лежит, если в системе > не предусмотрены проверки/схемы заполнения/схемы оформления и проч. - > кака таки будет. > о них. > > Любой класс Системы является так или иначе отображением бизнес-процессов > предприятия на структуру Системы. Документы и справочники не существуют > как вещь в себе, они организуют какую-то функцию. > > Я так понял - Вы утверждаете, что используя ограниченный инструменарий > настроек документов/справочников Вы в состоянии адекватно реализовать > систему реализующую бизнес процессы любого предприятия? так смело бы я не сказал, но... в целом очень близко. очччень близко. зы правда стоит сказать о настройке... начинали мы со структуры данных, а переключились уже на функционал, всё таки... скажем, используя некий внутренний язык нашей системы и обладая необходимыми знаниями самой системы и предметной области Вы можете покрыть практически любое предприятие. Вот такой вот лозунг в стиле 1-сы. ззы кста, клёвое слово - "покрыть". как бык овцу... -- ------------------------- There's no silver bullet! Posted via ActualForum NNTP Server 1.3 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.12.2005, 19:14 |
|
||
|
Модель данных по Тенцеру
|
|||
|---|---|---|---|
|
#18+
lockyТо исть, в зависимости от того, как я храню данные, я могу или не могу провести некую операцию??? если я храню карточки в шкафах - то могу, а если храню карточки в тумбочках - то не могу??? Несколько утрировано и нарочито. Но даже и здесь - в шкафах вы можете просмотреть взглядом разделы и карточки (как в библиотеке) а в тумбочках - придется открывать ящики, чтобы понять - есть там нужная карточка или нет. lockyиспользуя некий внутренний язык нашей системы и обладая необходимыми знаниями самой системы и предметной области Вы можете покрыть рактически любое предприятие. Вот такой вот лозунг в стиле 1-сы. Т.е. присутствует некий проблемно-ориентированый язык, который дополняет настраиваемую структуру документов/справочников и реализует особенности бизнес логики? Насколько я понимаю - это делается "пользователем", который открыв настройки документа/справочника прописывает некоторые функции? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.12.2005, 19:54 |
|
||
|
Модель данных по Тенцеру
|
|||
|---|---|---|---|
|
#18+
UrryMcA wrote: > locky > То исть, в зависимости от того, как я храню данные, я могу или не могу > провести некую операцию??? > если я храню карточки в шкафах - то могу, а если храню карточки в > тумбочках - то не могу??? > > Несколько утрировано и нарочито. Но даже и здесь - в шкафах вы можете > просмотреть взглядом разделы и карточки (как в библиотеке) а в тумбочках > - придется открывать ящики, чтобы понять - есть там нужная карточка или нет. Намеренно утрировано и нарочито, типа гипербола. Ха! то что мне надо открывать тумбочки значит только одно: для выполнения каких-то операций мне придется потратить больше времени. Это ведь не создает приницпиальную невозможность проведения операции, n'est-ce pas? > > locky > используя некий внутренний язык нашей системы и обладая необходимыми > знаниями самой системы и предметной области Вы можете покрыть рактически > любое предприятие. Вот такой вот лозунг в стиле 1-сы. > > Т.е. присутствует некий проблемно-ориентированый язык, который дополняет > настраиваемую структуру документов/справочников и реализует особенности > бизнес логики? Насколько я понимаю - это делается "пользователем", > который открыв настройки документа/справочника прописывает некоторые > функции? угу. Только юзер должен быть шибко грамотным :-) Не для него это всё, а для программера, если честно. поскоку в качестве внутреннего языка используется т-скл. И ваще, как то мы ушли в сторону от модели Тенцера и побрели в сторону легко-адаптируемых систем. Скоро сызнова призовём аскруса, который нам поведает тонкости реализации алгоритмов расчетов, привязанных к периодам :-) -- ------------------------- There's no silver bullet! Posted via ActualForum NNTP Server 1.3 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.12.2005, 20:11 |
|
||
|
Модель данных по Тенцеру
|
|||
|---|---|---|---|
|
#18+
накладывает определенные ограничения на функционал lockyЭто ведь не создает приницпиальную невозможность проведения операции Как мне кажется - я сказал несколько по другому. lockyИ ваще, как то мы ушли в сторону от модели Тенцера и побрели в сторону легко-адаптируемых систем. Насколько я понял - основным и главным преимуществом архитектуры "по Тенцеру" как раз и заявлялась эта самая "легко адаптируемость". А теперь еще оказывается lockyв качестве внутреннего языка используется т-скл. и целесообразность построения ERP(!!!) системы полностью по такой архитектуре требует таки квалифицированного специалиста. Короче пришли к тому, что я и ожидал. Очередной велосипед завода им.Лихачева. Можете не отвечать на мой пост locky. То, что Вы предлагаете я уже не раз видел. Дальнейшее описание Вашей без сомнения супер Системы меня уже не интересует. Спасибо и до свидания. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.12.2005, 20:29 |
|
||
|
Модель данных по Тенцеру
|
|||
|---|---|---|---|
|
#18+
UrryMcA wrote: > > и целесообразность построения ERP(!!!) системы полностью по такой > архитектуре требует таки квалифицированного специалиста. > > Короче пришли к тому, что я и ожидал. Очередной велосипед завода > им.Лихачева. > > Можете не отвечать на мой пост locky. То, что Вы предлагаете я уже не > раз видел. Дальнейшее описание Вашей без сомнения супер Системы меня уже > не интересует. Спасибо и до свидания. ваще-то я рассматривал Тенцера не с точки зрения меня как внедренца/пользователя, а с точки зрения меня как программера. Никто не спорит - очередной велосипед, может быть даже имени Лихачева. И систем подобной архитектуры сейчас - через одну, ежели не 2 из 3-х... удобно для разработки, знаете ли... не коробки пишем, под заказ... В коробках - это 1С, как её не ругают, а франчайзи довольны... мы же можем себе позволить использовать т-скл для настройки - сами то и настраиваем, да и обучить толкового прогера заказчика - проблема относительно небольшая. Зато достигается значительная скорость работы - всё ж родное, нативное :-) -- ------------------------- There's no silver bullet! Posted via ActualForum NNTP Server 1.3 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.12.2005, 12:06 |
|
||
|
Модель данных по Тенцеру
|
|||
|---|---|---|---|
|
#18+
ГЫ! Снова за старое!? ЗЫ Считаю, что уже пришло время когда адекватного специалиста по проектированию БД можно будет выявлять в том числе с помощью вопроса: что он думает про модель Тенцера... Адекватным должно быть, во-первых, известно, что EAV люди знали задолго до Тенцера и в книгах по проектированию уделяли ей обычно не более пары страниц, во-вторых, что это не модель данных, в третьих, что утверждение "объектная модель хорошо ложится на модель Тенцера" выдает, что говорящий не понимает предмета, в-четвертых ... ну и т.д. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 24.12.2005, 01:02 |
|
||
|
Модель данных по Тенцеру
|
|||
|---|---|---|---|
|
#18+
funikovyuri wrote: > ГЫ! Снова за старое!? а то! > > в третьих, что утверждение "объектная модель > хорошо ложится на модель Тенцера" выдает, что говорящий не понимает > предмета, в-четвертых ... ну и т.д. хм.. у меня справочники - почти что объекты, тем паче что в силу реализации работать с изменением в них данных приходится исключительно через спец-апи :-( Никаких тебе прямых обновлений таблиц... заполнил параметры вызова, вызвал обработчик... и в каждом втором справочнике перекрыты методы создания/редактирования/проверки/удаления с вызовом inherited методов :-) очень похоже. Хотя и не объекты. -- ------------------------- There's no silver bullet! Posted via ActualForum NNTP Server 1.3 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 24.12.2005, 12:34 |
|
||
|
Модель данных по Тенцеру
|
|||
|---|---|---|---|
|
#18+
nnovУ кого какие мнения по поводу модели Тенцера 1) Использую что-то подобное, "кустарно" расширенную EAV. Меня устраивает. Объёмы, правда, пока небольшие - 8 классов объектов, у каждого ~ 1000 свойств. ~400 экземпляров. Быстродействие - вполне: СУБД умеет неплохо оптимизировать запросы, если не слишком "мудрить" с ними. 2) По-моему, часть данных, структура которых часто и непредсказуемо меняется ("пользовательских") можно хранить по такой модели. Более-менее стабильные ("системные") - не имеет смысла: а) сложность ведения б) ресурсоёмкость 3) Система получается универсальнее, чем нужно на данный момент. Т.е. может получиться сложнее и дороже сначала, а что потом будет легче и проще - никто не гарантирует. Лично для меня это вполне - предметная область такая: поддержка принятия решений при сертификации, притом, что сертификационные требования (=>структуры паспортов объектов) изменяются, классы добавляются и т.д. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.01.2006, 13:06 |
|
||
|
Модель данных по Тенцеру
|
|||
|---|---|---|---|
|
#18+
Закину ка я сюда для примера один из запросов из системы Тенцера, что бы ощутить глубину так сказать... Взят из конфы, пытался его несколько отформатировать, для прочтения но не очень-то получилось. Видел этот запрос ДО и ПОСЛЕ прочтения статьи. ДО - непонятно вообще нифига. ПОСЛЕ - уже можно ковыряться. Hello Igor. Вторник Февраль 27 2001 12:19, you wrote to All: IT> ПРИМЕР ТЕнцера в студию! Пущай Попов покажет этим MSSQL'истам! на деле примеров от Анатолия была куча и куда более большие, а это видимо, то, что под руку попалось. -=== Cut ===- Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. 24. 25. 26. 27. 28. 29. 30. 31. 32. 33. 34. 35. 36. 37. 38. 39. 40. 41. 42. 43. 44. 45. 46. 47. 48. 49. 50. 51. 52. 53. 54. 55. 56. 57. 58. 59. 60. 61. 62. 63. 64. 65. 66. 67. 68. 69. 70. 71. 72. 73. 74. 75. 76. 77. 78. 79. 80. 81. 82. 83. 84. 85. 86. 87. 88. 89. 90. 91. 92. 93. 94. 95. 96. 97. 98. 99. 100. 101. 102. 103. 104. 105. -=== Cut ===- а записей там под 10М. Andrew ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.01.2006, 13:59 |
|
||
|
Модель данных по Тенцеру
|
|||
|---|---|---|---|
|
#18+
fraks wrote: > Закину ка я сюда для примера один из запросов из системы Тенцера, что бы > ощутить глубину так сказать... > Взят из конфы, пытался его несколько отформатировать, для прочтения но > не очень-то получилось. > > Видел этот запрос ДО и ПОСЛЕ прочтения статьи. > ДО - непонятно вообще нифига. > ПОСЛЕ - уже можно ковыряться. у нас до 70-ти и более джойнов доходит.... -- ------------------------- There's no silver bullet! Posted via ActualForum NNTP Server 1.3 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.01.2006, 18:49 |
|
||
|
Модель данных по Тенцеру
|
|||
|---|---|---|---|
|
#18+
fraks Код: plaintext Какой ужас! Может быть, мы что-то неправильно делаем, но у нас всё проще и при этом работает:). Правда, о модели Тенцера я не говорю - только о EAV, несколько расширенной для хранения исторических данных. К примеру, извлечение свойства сертифицируемого объекта в EAV: Код: plaintext 1. 2. 3. 4. 5. 6. 7. При этом от JOIN'а вообще можно избавиться, применив WHERE healing_object_property_id IN (subquery). Хотя я подозреваю, что оптимизатор уже делает это. Если бы модель была ROT, "1 класс = 1 таблица", было бы, наверное: Код: plaintext 1. 2. 3. По-моему, возможность безболезненно добавлять и изменть свойства, а также хранить исторические данные вполне стоит выполнения одного дополнительного JOIN'а или одного дополнительного подзапроса. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 12.01.2006, 11:26 |
|
||
|
Модель данных по Тенцеру
|
|||
|---|---|---|---|
|
#18+
Я тут немного томожу по болезни, но Вы мне объясните сакральный смысл: Зачем делать много join в запросе при выборе свойств объекта? Для того, чтобы resultset вернулся в виде таблицы со всемы свойствами "развернутыми" в колонки? У меня такой ORM делается на уровне бизнес - логики. Или я таки что-то не понял? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.01.2006, 16:54 |
|
||
|
Модель данных по Тенцеру
|
|||
|---|---|---|---|
|
#18+
UrryMcAДля того, чтобы resultset вернулся в виде таблицы со всемы свойствами "развернутыми" в колонки? У меня такой ORM делается на уровне бизнес - логики. Или я таки что-то не понял? Тогда я не наверное чего-то не понял разворачивать грид из десятков колнок и нескольких сот строк по 1 полю на клиенте? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.01.2006, 17:21 |
|
||
|
Модель данных по Тенцеру
|
|||
|---|---|---|---|
|
#18+
Estets UrryMcAДля того, чтобы resultset вернулся в виде таблицы со всемы свойствами "развернутыми" в колонки? У меня такой ORM делается на уровне бизнес - логики. Или я таки что-то не понял? Тогда я не наверное чего-то не понял разворачивать грид из десятков колнок и нескольких сот строк по 1 полю на клиенте? У меня аналогично разворачивается на клиенте в коллекцию объектов, а грид биндится уже к этой коллекции. Вычислительных затрат на это ИМХО меньше, чем на такой сложный запрос. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.01.2006, 20:05 |
|
||
|
Модель данных по Тенцеру
|
|||
|---|---|---|---|
|
#18+
VladiChВычислительных затрат на это ИМХО меньше, чем на такой сложный запрос. На самом деле не факт. Я не делал даже предварительных расчетов оптимизации производительности реализованой схемы. Просто она оказалась супер простой в реализации, и прошла через требования по быстродействию. Вполне кстати может оказаться, что предложеный запрос при определенных условиях перекроет по производительности мой "тупой" метод. Другое дело, что я применяю оптимизированный object pool и поэтому разница в производительности вполне может быть им скомпенсирована. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.01.2006, 23:10 |
|
||
|
Модель данных по Тенцеру
|
|||
|---|---|---|---|
|
#18+
UrryMcA VladiChВычислительных затрат на это ИМХО меньше, чем на такой сложный запрос. На самом деле не факт. Я не делал даже предварительных расчетов оптимизации производительности реализованой схемы. Просто она оказалась супер простой в реализации, и прошла через требования по быстродействию. Вполне кстати может оказаться, что предложеный запрос при определенных условиях перекроет по производительности мой "тупой" метод. Другое дело, что я применяю оптимизированный object pool и поэтому разница в производительности вполне может быть им скомпенсирована. В моем случае - однозначно меньше. Проверял. Чем больше количество полей, которых из вертикальной выборки нужно перевести в горзонтальную, а также чем больше количество записей в выборке, тем выгоднее собирать такие записи на клиенте. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.01.2006, 15:12 |
|
||
|
Модель данных по Тенцеру
|
|||
|---|---|---|---|
|
#18+
Жаль, не обратил раньше внимание на топик. Я хочу на базе такой фиговины описать "групповые спецификации" и "групповую технологию". Стоит ли развивать? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.01.2006, 23:07 |
|
||
|
Модель данных по Тенцеру
|
|||
|---|---|---|---|
|
#18+
to: Сахават Юсифов В таком случае "сопроводиловку" было бы неплохо написать. "Развернуть" так сказать тему. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.01.2006, 23:32 |
|
||
|
Модель данных по Тенцеру
|
|||
|---|---|---|---|
|
#18+
UrryMcAto: Сахават Юсифов В таком случае "сопроводиловку" было бы неплохо написать. "Развернуть" так сказать тему. Это как раз тот случай, о котором Вы говорили - Свойства продукция и групповые технологии ориентированные на применение свойств продукции. Продукция может иметь разные свойства. "Цвет", "8 клапанный мотор". Все это дело закодировать как модификацию - муторно. Автомобиль - состоит - кузов, мотор. Кузов - свойство - цвет, мотор - свойство "количество клапанов". Надо описать автомобиль (базовый, что ли). А при конфигурации заказа приписывать нужные свойства (или по умолчанию). Дальше идет операция. "Сбока кузова". На входе краски, на выходе окрашенный кузов. Опять по свойству надо выбрать нужные материалы, нужные группы. Сумбурно, но что делать. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.01.2006, 00:16 |
|
||
|
Модель данных по Тенцеру
|
|||
|---|---|---|---|
|
#18+
Сахават Юсифов пишет: > Сумбурно, но что делать. Вот что-то подобное сам пытаюсь реализовать и тоже пока сумбурно. Принцип примерно такой. В спецификациях указываются как реальные изделия/комплектующие/сырье, независящие от свойств, так и "базовые изделия". Например "ткань". Ткань имеет свойство цвет. По цвету можно определить какую именно ткань нужно взять. При раскрытии спецификации на конкретное изделие, имеющее набор определяющих свойств, строчки с такими "базовыми изделиями" заменяются на фактические комплектующие путем сопоставления свойств. Posted via ActualForum NNTP Server 1.3 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.01.2006, 17:19 |
|
||
|
Модель данных по Тенцеру
|
|||
|---|---|---|---|
|
#18+
Александр Гoлдун Сахават Юсифов пишет: > Сумбурно, но что делать. Вот что-то подобное сам пытаюсь реализовать и тоже пока сумбурно. Принцип примерно такой. В спецификациях указываются как реальные изделия/комплектующие/сырье, независящие от свойств, так и "базовые изделия". Например "ткань". Ткань имеет свойство цвет. По цвету можно определить какую именно ткань нужно взять. При раскрытии спецификации на конкретное изделие, имеющее набор определяющих свойств, строчки с такими "базовыми изделиями" заменяются на фактические комплектующие путем сопоставления свойств. Posted via ActualForum NNTP Server 1.3 Дальше еще интересней. По совместимости свойств выбирается операция, входы операций и по правилам (групповое свойство) уточняется операционное время. Эта структура позволяет все это сделать. Интересный побочный эффект - свойства выступают как коллекции объектов, да вообще тут куча вещей. Надо бы приделать группировку свойств. А как красиво (автоматом) получаются списки, деревя, гравы и т.д. Закончу текущий проект и возмусь за это дело серьезно. И, между прочим, это не модель Тенцера. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.01.2006, 19:18 |
|
||
|
Модель данных по Тенцеру
|
|||
|---|---|---|---|
|
#18+
"модель Тенцера" 8[. РРРррр! Я щасс статью напишу по мотивам таблицы Менделеева!! Пусть все эту таблицу больше не называют "таблица Менделеева"!! Теперь это будет таблица Urry!! ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.01.2006, 10:51 |
|
||
|
Модель данных по Тенцеру
|
|||
|---|---|---|---|
|
#18+
UrryMcA"модель Тенцера" 8[. РРРррр! Я щасс статью напишу по мотивам таблицы Менделеева!! Пусть все эту таблицу больше не называют "таблица Менделеева"!! Теперь это будет таблица Urry!! Мотивы - химия и ООП. Тенцер, так Тенцер, тем более фамилия звучная. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.01.2006, 11:17 |
|
||
|
Модель данных по Тенцеру
|
|||
|---|---|---|---|
|
#18+
Молодец, Анатолий. Еще при своей жизни заставил недорослей называть реализацию схемы с вертикальным хранением атрибутов средствами РСУБД моделью, да еще и по своей фамилии. Тенцеру зачёт, однозначно :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 31.01.2006, 18:56 |
|
||
|
Модель данных по Тенцеру
|
|||
|---|---|---|---|
|
#18+
Templar wrote: > Молодец, Анатолий. > Еще при своей жизни заставил недорослей называть реализацию схемы с > вертикальным хранением атрибутов средствами РСУБД моделью, да еще и по > своей фамилии. > Тенцеру зачёт, однозначно :) Сам такой и сам недоросль! :-) назвали так тему, и шобы не сбивать - нехай и модель так зовётся... тем паче что начАли обсуждать конкретную реализацию, а потом ужо скатились... -- ------------------------- There's no silver bullet! Posted via ActualForum NNTP Server 1.3 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 31.01.2006, 19:20 |
|
||
|
Модель данных по Тенцеру
|
|||
|---|---|---|---|
|
#18+
Даите пожалуйста ссылку на статью Тенцера! ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.02.2006, 15:34 |
|
||
|
Модель данных по Тенцеру
|
|||
|---|---|---|---|
|
#18+
Inna-- wrote: > Даите пожалуйста ссылку на статью Тенцера! в первой мессаге трэда -- ------------------------- There's no silver bullet! Posted via ActualForum NNTP Server 1.3 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.02.2006, 16:37 |
|
||
|
Модель данных по Тенцеру
|
|||
|---|---|---|---|
|
#18+
2 Inna: ищите в архиве за 2001 год №8 на compress.ru ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.02.2006, 15:43 |
|
||
|
Модель данных по Тенцеру
|
|||
|---|---|---|---|
|
#18+
Пытаюсь описать производство такой структурой. Насколько адекватно? Насколько выгодно? Или пойти проверенным путем - машины, люди, детали, материалы...? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.02.2006, 17:23 |
|
||
|
Модель данных по Тенцеру
|
|||
|---|---|---|---|
|
#18+
nnov Я конечно еще не пробовал, реально, но мне кажется что именно документы т.е. объекты с которыми производиться много групповых операций и по которым троятся практически все отчеты в такой схеме будут давать большие тормоза. Да остаток по одному счету получаем с небольшой разницей по времени 1-2 секунды можно не принимать во внимание, У Тенцера для этих целей работает хранилище данных, где данные складируются уже в нормальной классической форме. Так что проблем нет. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.02.2006, 20:22 |
|
||
|
Модель данных по Тенцеру
|
|||
|---|---|---|---|
|
#18+
Old NickНасчет плохого быстродействия в базе, спроектированной по теории Тенцера - сказки. Кто-нибудь проверял это? Или это ваши предположения? Это проверял он сам. Быстродействие приемлимое. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.02.2006, 20:27 |
|
||
|
Модель данных по Тенцеру
|
|||
|---|---|---|---|
|
#18+
to Сахават Юсифов: Вот если бы Вы еще внятно словами объяснять научились, что Вы хотите реализовать - тогда можно было бы с Вами поговорить с пользой. Несмотря на интерес к ORM в производственных системах разбирать структуру связей сущностей показаных в виде таблиц БД - как то влом. Гадать о том, что вы пытаетесь сказать - забавы людей с большим количеством свободного времени. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.02.2006, 22:35 |
|
||
|
Модель данных по Тенцеру
|
|||
|---|---|---|---|
|
#18+
UrryMcAto Сахават Юсифов: Вот если бы Вы еще внятно словами объяснять научились, что Вы хотите реализовать - тогда можно было бы с Вами поговорить с пользой. Несмотря на интерес к ORM в производственных системах разбирать структуру связей сущностей показаных в виде таблиц БД - как то влом. Гадать о том, что вы пытаетесь сказать - забавы людей с большим количеством свободного времени. Да не знаю насколько это имеет отношение к ОРМ. Проблема вот какая. Ну, написал я МЕС. Базовое предприятие относится к деревообработке. А до этого много работал с машиностроением. Естественно учел (насколько знал и насколько смог) и то, и другое. Оказалось, что машиностроение (ИМХО - больше повторять не буду) проще, чеим деревообработка. Но тут кто-то просил металлопродукцию, другой кабель и т.д. И везде мелький, но затык. Конечно, я могу за неделю другую сунуть и эти особенности и расширить прогу, но не дело. А все затыки связаны с свойствами объектов. Вроде и там и тут материалы, машины, люди, технроцессы..., но все чуть-чуть отличаются. Да что там отрасли, невозможно описать материал - Лист сталь такая-то имеет свойства - марка, толщина, ширина и т.д., а краска - цвет, базу, срок годности и т.д. Изделия называется нож кухонный, а призаказе просят - нож кухонный, из нержавейки, не длиннее 20 см, не тяжелую, приятного цвета, с кожаной кобурой синего цвета. Вот пытаюсь решить эту проблему один раз, что бы дальше не мучиться. Создаю идентификатор для объекта, приписываю его к типу (если надо), тип к супертипу (если надо), приписываю уникальные свойства непосредственно к самому объекту. Тип и супертип имеют свои коллекции свойств. При идентификации объекта все свойства собираются из трех коллекций свойств. Значения свойств хранятся в трех хранилищах (пока символьной с указанием базового типа - может ToString обойдусь, если нет то расширить не проблема.) А остальную логику (процессы и т.д.) так описывать не выгодно, во всяком случае пока не вижу выгоду. Вот и все. Тут есть одно но. UI - как смогу всю эту гадость удобно визуализировать. Наверное, придется управление данными выводить в отдельную не красивую рожу. Посмотрим, сейчас БД до конца доведу, там видно будет. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.02.2006, 00:09 |
|
||
|
Модель данных по Тенцеру
|
|||
|---|---|---|---|
|
#18+
Сахават ЮсифовТип и супертип имеют свои коллекции свойств. При идентификации объекта все свойства собираются из трех коллекций свойств. Конечно тип, супертип - этотак для начала, если пойдет, то сделаю граф типов. Тогда можно будет описать все что угодно. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.02.2006, 00:13 |
|
||
|
Модель данных по Тенцеру
|
|||
|---|---|---|---|
|
#18+
Сахават ЮсифовНу, написал я МЕС Принцип вот какой: Ядро системы, реализующее некоторый набор моделей, фиксируется в обычных таблицах с жесткой неизменяемой структурой, оптимизированной по скорости обработки. Параметры моделей т.е. все что может меняться: объекты, документы, справочники, классификаторы и пр. хранятся по EAV. Бизнес-логика тоже изменяемая и имеет доступ ко всем параметрам и их атрибутам. Испробовано - работает ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.02.2006, 11:16 |
|
||
|
Модель данных по Тенцеру
|
|||
|---|---|---|---|
|
#18+
Сахават, а связи между объектами? Если включить и обобщенную модель связей, то ИМХО окажется, что процессы - тоже объекты. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.02.2006, 11:17 |
|
||
|
Модель данных по Тенцеру
|
|||
|---|---|---|---|
|
#18+
Вот это правильная статья Тенцера? База данных — хранилище объектов http://compress.ru/Archive/CP/2001/8/9/ только она и есть на compess.ru в архиве 2001/8 номера ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.02.2006, 12:08 |
|
||
|
Модель данных по Тенцеру
|
|||
|---|---|---|---|
|
#18+
> Вот пытаюсь решить эту проблему один раз, что бы дальше не мучиться. Imho не получилось. Представленная Вами схема: 1. нестандартна, 2. не расширяема, 3. имеет ограниченный функционал. В общем, до Тенцера - недалеко: те же яйца, только в профиль. Из плюсов отмечу, что Вы попытались прикрутить нормальный словарь. Правда, странным образом, избирательно. > А остальную логику (процессы и т.д.) так описывать не выгодно, во всяком > случае пока не вижу выгоду. Вы сильно удивитесь, если я скажу, что принципиальной разницы между описанием процессов или сущностей нет? > как смогу всю эту гадость удобно визуализировать. А зачем, позвольте поинтересоваться? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.02.2006, 12:27 |
|
||
|
Модель данных по Тенцеру
|
|||
|---|---|---|---|
|
#18+
guest_20040621> Вот пытаюсь решить эту проблему один раз, что бы дальше не мучиться. Imho не получилось. Представленная Вами схема: 1. нестандартна, 2. не расширяема, 3. имеет ограниченный функционал. В общем, до Тенцера - недалеко: те же яйца, только в профиль. 1. А есть стандарты? Где посмотреть? 2. Если выкинуть тип и супертип заменив их графом 'объект<-объект' ,можно добиться расширяемости по части наследования (если я правильно понял смысл Вашей расширяемости) свойств минимальной структурой. Но, я хотел бы контролировать определенные системные вещи и лучше просто добавить к имеющиейся струкутуре 'объект<-объект', потому что, если оставить минимальную структуру велика вероятность потери базовых структур, да наверное усложнится семантика и т.д.. 3. Функционал, пока что, наследование свойств на уровне типа. Если это достигнут???, то уже хорошо. [/quot] guest_20040621 Из плюсов отмечу, что Вы попытались прикрутить нормальный словарь. Правда, странным образом, избирательно. Не знаю, что Вы имеете в виду говоря о словаре и избирательности. Цель была такая. 1. Описать не зависимый единичный объект. 2. Если задан тип с подходящими свойствами, то можно унаследовать свойства этого типа. (Хотелось бы избирательно) 3. Зная, что все универсальное не всегда работает, захотелось задать супертип для базовых структур. Можно обойтись без типа и супертипа. guest_20040621 Вы сильно удивитесь, если я скажу, что принципиальной разницы между описанием процессов или сущностей нет? Сам процесс как сущности и отношения - да ради бога. А вот отношение предшествования хотелось бы задать неявно . Да и вообще говоря процессная часть самоценна и более значима чем объектная и поэтому я не стал бы усложнят логику и потерят визуальный контрол из за того что бы сэкономить несколько таблиц. guest_20040621 > как смогу всю эту гадость удобно визуализировать. А зачем, позвольте поинтересоваться? Хочется сделать конструктор с командами типа "создать процесс", "создать объект", "соединить" и "включить в коллекцию" т.д. В общем, цел визуализация структур, технологий, хода производства. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.02.2006, 14:05 |
|
||
|
Модель данных по Тенцеру
|
|||
|---|---|---|---|
|
#18+
> 1. А есть стандарты? Я знаю минимум два: MOF и CIM. MOF - imho более употребителен, если можно так выразиться. > 2. Если выкинуть тип и супертип заменив их графом 'объект<-объект' Нет, дело не в этом. Вы реализовали схему просто как схему. Я предлагаю подумать над вариантом более рациональным: реализовать схему как часть спецификации, парадигмы или модели. > можно добиться расширяемости по части наследования Расширяемость я рассматриваю как возможность описания новой модели в той же структуре данных и описания реализации в терминах новой модели без изменения структуры данных. > Цель была такая. Понятно. Imho один уровень абстракции Вы пропустили. ;) > Хочется сделать конструктор с командами типа "создать процесс", > "создать объект", "соединить" и "включить в коллекцию" т.д. Imho реализация этого на хорошем уровне потребует написания визуального редактора (типа тузлы для UML моделирования). Причем в Вашем случае он будет опять же абсолютно нестандартным. ;) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.02.2006, 14:53 |
|
||
|
Модель данных по Тенцеру
|
|||
|---|---|---|---|
|
#18+
А вот так? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.02.2006, 15:03 |
|
||
|
Модель данных по Тенцеру
|
|||
|---|---|---|---|
|
#18+
Сахават ЮсифовА вот так? По-моему, как-то сложно... Для того, чтобы не испугаться супертипов, пользователь должен быть хорошим программистом. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.02.2006, 16:03 |
|
||
|
Модель данных по Тенцеру
|
|||
|---|---|---|---|
|
#18+
AlexTheRaven Сахават ЮсифовА вот так? По-моему, как-то сложно... Для того, чтобы не испугаться супертипов, пользователь должен быть хорошим программистом. В общем случае супертип можно заменить на граф наследования Parent_Type->Type. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.02.2006, 16:22 |
|
||
|
Модель данных по Тенцеру
|
|||
|---|---|---|---|
|
#18+
В свое время, разбираясь с универсальными структурами, нарисовал следующую цепочку. 1. Исходные схемы 1.1. Объекты, классы и "простые" свойства. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 07.02.2006, 09:31 |
|
||
|
Модель данных по Тенцеру
|
|||
|---|---|---|---|
|
#18+
1.2.Связи (отношения) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 07.02.2006, 09:32 |
|
||
|
Модель данных по Тенцеру
|
|||
|---|---|---|---|
|
#18+
2. Обобщение ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 07.02.2006, 09:33 |
|
||
|
Модель данных по Тенцеру
|
|||
|---|---|---|---|
|
#18+
3.Обобщенная модель. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 07.02.2006, 09:35 |
|
||
|
Модель данных по Тенцеру
|
|||
|---|---|---|---|
|
#18+
Это всего лишь наскальные изображения и без ортодоксального программизма тут не обойтись! ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 07.02.2006, 10:12 |
|
||
|
Модель данных по Тенцеру
|
|||
|---|---|---|---|
|
#18+
ModelR3.Обобщенная модель. То же , что и я нарисовал. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 07.02.2006, 10:21 |
|
||
|
Модель данных по Тенцеру
|
|||
|---|---|---|---|
|
#18+
> нарисовал следующую цепочку Те же ограничения, что и у Сахавата, и у Old Nick. ModelR, а Вам что помешало реализовать стандартную модель? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 07.02.2006, 11:35 |
|
||
|
Модель данных по Тенцеру
|
|||
|---|---|---|---|
|
#18+
А что за ограничения? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 07.02.2006, 12:20 |
|
||
|
Модель данных по Тенцеру
|
|||
|---|---|---|---|
|
#18+
guest_20040621> нарисовал следующую цепочку Те же ограничения, что и у Сахавата, и у Old Nick. ModelR, а Вам что помешало реализовать стандартную модель? В чистом виде я ее вообще не реализовывал. Жизнь всегда сложнее. Однако разбираться с тем, что наворочено в очередной чудо-системе помогает. Что касается ограничений - это же не средство генерации/взаимодействия средств проектирования как MOF. Задача была проще разобраться - что есть ФАКТ . ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 07.02.2006, 12:43 |
|
||
|
Модель данных по Тенцеру
|
|||
|---|---|---|---|
|
#18+
Old NickА что за ограничения? > 1. нестандартна, 2. не расширяема, 3. имеет ограниченный функционал. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 07.02.2006, 13:08 |
|
||
|
Модель данных по Тенцеру
|
|||
|---|---|---|---|
|
#18+
> В чистом виде я ее вообще не реализовывал. Стойкое ощущение, что Вашей целью было [упрощенно] описать что-то типа стандарта SQL. При этом непонятно, для какой цели опущены некоторые из ключевых понятий стандарта и непонятно, для какой цели используется отличный от стандартного словарь. > Жизнь всегда сложнее. Собственно, я и интересуюсь, зачем создавать дополнительные проблемы. > Однако разбираться с тем, что наворочено в очередной чудо-системе помогает. Неожиданное прикладное применение. > Задача была проще разобраться - что есть ФАКТ. Простите мне мою тупость, но не могли бы Вы на пальцах объяснить, что в Вашей схеме есть ФАКТ? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 07.02.2006, 13:09 |
|
||
|
Модель данных по Тенцеру
|
|||
|---|---|---|---|
|
#18+
guest_20040621> .... Посмотрел MOF. Каждый изголяется как может. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 07.02.2006, 14:48 |
|
||
|
Модель данных по Тенцеру
|
|||
|---|---|---|---|
|
#18+
А кто-нибудь может сказать почему бы не использовать не много таблиц свойств объектов, каждая для своего типа, как у Тенцера, а одну, у которой все данные хранятся в поле с типом sql_variant ? Интересно как это влияет на производительность ? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 07.02.2006, 16:07 |
|
||
|
Модель данных по Тенцеру
|
|||
|---|---|---|---|
|
#18+
guest_20040621 Простите мне мою тупость, но не могли бы Вы на пальцах объяснить, что в Вашей схеме есть ФАКТ? Функция P: X -> Z Cвойство p объекта x имеет значение [объект] z. "Цвет МЦ-14 красный" Роль р в экземпляре x n-арной связи играет [объект] z. "Назначенным в приказе 2134 является Сидоров" Бинарным функциональным отношением p объект x связан с [объектом] z. "Авто1 имеет коробку передач АБ09" ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 07.02.2006, 16:23 |
|
||
|
Модель данных по Тенцеру
|
|||
|---|---|---|---|
|
#18+
А кто-нибудь может сказать почему бы не использовать не много таблиц свойств объектов, каждая для своего типа, как у Тенцера, а одну, у которой все данные хранятся в поле с типом sql_variant ? Интересно как это влияет на производительность ? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 07.02.2006, 16:40 |
|
||
|
Модель данных по Тенцеру
|
|||
|---|---|---|---|
|
#18+
> Посмотрел MOF. А теперь посмотрите на Вашу схему: она часть MOF и реализует. ;) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 07.02.2006, 18:24 |
|
||
|
Модель данных по Тенцеру
|
|||
|---|---|---|---|
|
#18+
> P: X -> Z Поправьте меня, если я ошибаюсь, но imho ровной такой же функционал реализуют системные таблицы СУБД. В чем фишка Вашей реализации? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 07.02.2006, 18:27 |
|
||
|
Модель данных по Тенцеру
|
|||
|---|---|---|---|
|
#18+
ОлегМА кто-нибудь может сказать почему бы не использовать не много таблиц свойств объектов, каждая для своего типа, как у Тенцера, а одну, у которой все данные хранятся в поле с типом sql_variant ? Минус место в базе (что самое существенное). Минус переносимость на другую СУБД. Производительность преобразований вариантов -- фиг с ним, но все равно же придется преобразовывать в конкретный тип данных, чтобы клиент понял ? Разве нет ? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 07.02.2006, 18:55 |
|
||
|
Модель данных по Тенцеру
|
|||
|---|---|---|---|
|
#18+
guest_20040621> Посмотрел MOF. А теперь посмотрите на Вашу схему: она часть MOF и реализует. ;) Я не ругал MOF. Просто уровень копания разный. А , вообще, кажется, что все это лишний геморрой. Через полгода сам забудешь что сваял, а другие тем паче. Просто не знаю окупится ли все это, не лучше ли остановиться на уровне наследования свойств? Как Вы думаете? Чесно говоря, я дальнейшую жизнь всего это не продумал, но маячать генераторы таблиц, правила, ограничения ... + ,все равно, семантика предметной области. Получается СУБД в СУБД? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 07.02.2006, 20:37 |
|
||
|
Модель данных по Тенцеру
|
|||
|---|---|---|---|
|
#18+
> Просто уровень копания разный. Да нет же, абсолютно одинаковый. ;) Модель Тенцера - это метамодель. Пусть примитивная, но метамодель. Ваша схема - это тоже метамодель. Сложнее, больше функционала, выше уровень абстракции, - да, но при этом нет качественного перехода. Что происходит: Вы отказываетесь от реляционной модели (т. е. расширяете SQL-2003 (или какой СУБД Вы пользуетесь?) метамодель) в обмен на хм... некоторые дополнительные возможности. Причем, расширяете одноразово, т. е. Ваша дополнительная метамодель никак не связана с метамоделью СУБД. Imho можно отказаться от реляционной модели - но в обмен на радикальное изменение функционала + сохранение возможностей реляционной модели. ;) > А , вообще, кажется, что все это лишний геморрой. Но ведь зачем-то Вы эту схему создали (причем, не один вариант)? Вряд ли просто потому, что было немного свободного времени. ;)) > Просто не знаю окупится ли все это Imho не окупится; скорее эта задача [пока] из разряда теоретических. > Получается СУБД в СУБД? Можно сказать и так. По сути - система хранения метаданных + СУБД. В чем фишка такой реализации (если кто-то когда-то до нее доберется, конечно): возможность описания любых (почти любых, - дальше "любых" с той же оговоркой) данных, возможность оперирования данными (причем, разнородными; например, реляционными и xml-подобными) внешних источников, возможность маппинга данных разных источников, дополнительный функционал (например, контроль доступа на разных уровнях), возможность описания данных в разных моделях одновременно и пр. В общем, много чего можно придумать. ;) Плохо то, что MOF модель (супермодель, метаметамодель) плохо ложится на реляционную структуру: она xml-подобна. К сожалению, я не знаю о заслуживающих внимания реализациях хранения xml файлов в реляционной стрктуре данных (не тупым маппингом, а с использованием xsd-like метамодели). ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 07.02.2006, 22:52 |
|
||
|
Модель данных по Тенцеру
|
|||
|---|---|---|---|
|
#18+
guest_20040621>Но ведь зачем-то Вы эту схему создали (причем, не один вариант)? Вряд ли просто потому, что было немного свободного времени. ;)) Да я же говорил. Расписание для дискретного производства (в данный момент я занят этим) не зависит от объекта производства. Но задать "что" надо изготовить и из "чего" - оказалось не так просто. Табличка описывающая входы и выходы техпроцесса меняется почти польностью в зависимости от отрасли. Остается одно поле - ID. Даже наименование объектов зависят от их свойств (вернее от унаследованных от самого процесса ("каленый") и составляющих("шпон дубовый")) - Получается "Дверь ххх ууу шпон дуб, засов каленый". Понятно, что народ всю эту белиберду "кодирует" - "00001". Но, как Вы знаете, при таком разнообразии кодировка должна подчинятся определенному алгоритму, а этот алгоритм человеку (менеджеру) не понятен и такие коды невозможно не запоминать, не воспроизвести в мозгах (По этому в бухгалтерии одни и те же ящики под разными кодами и наоборот). Вот я и хочу унаследовать значимые свойства процессов и их входов для выходов процесса. Решается вопрос идентификации и конфигурации. Побочно это привела к универсальному способу хранения объектов и их свойств. Определенная часть наследуется, а другая уникальна для каждого объекта (именно объекта.) guest_20040621 Imho не окупится; скорее эта задача [пока] из разряда теоретических. Для себя жизнь облегчить можно. А если постараться, то и для других. Плохо получается механизм хранения для собственных свойств отношения, приходится сгенерировать объект-суррогат и включять его в отношение для 1->1 c объектной хранилищей и вешать на него собственные свойства отношения. Интересно, как другие это реализовали? (Генерировать таблицы для каждого отношения в счет не берем.) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 08.02.2006, 00:29 |
|
||
|
Модель данных по Тенцеру
|
|||
|---|---|---|---|
|
#18+
guest_20040621 Imho не окупится; скорее эта задача [пока] из разряда теоретических. Вы меня разозлили.:) Вот минимальная структура с помощью которой можно описать все. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 08.02.2006, 02:53 |
|
||
|
Модель данных по Тенцеру
|
|||
|---|---|---|---|
|
#18+
Сахават ЮсифовПолучается СУБД в СУБД? Именно так.За исключением физических характеристик и оптимизатора:). ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 08.02.2006, 10:02 |
|
||
|
Модель данных по Тенцеру
|
|||
|---|---|---|---|
|
#18+
guest_20040621> P: X -> Z Поправьте меня, если я ошибаюсь, но imho ровной такой же функционал реализуют системные таблицы СУБД. В чем фишка Вашей реализации? Словарь данных приложения не обязательно со словарем данных СУБД, а в системах практической сложности всегда используется свой словарь данных. Один и тот же факт в таблицы можно положить по разному, например традиционно (X - ключ, P - неключевой атрибут, Z - значение P), EAV, но факт остается фактом, соответственно строится обмен между разными системами. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 08.02.2006, 11:21 |
|
||
|
Модель данных по Тенцеру
|
|||
|---|---|---|---|
|
#18+
> Вот минимальная структура с помощью которой можно описать все. "Все" в смысле все, что отвечает Вашим задачам? Или вообще любую структуру? ;) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 08.02.2006, 11:39 |
|
||
|
Модель данных по Тенцеру
|
|||
|---|---|---|---|
|
#18+
> Словарь данных приложения не обязательно со словарем данных СУБД, а в системах практической > сложности всегда используется свой словарь данных. Если я правильно Вас понял, любое уважающее себя приложение должно иметь не только собственную модель данных, но и собственную метамодель? ;)) > Один и тот же факт в таблицы можно положить по разному, Я не увидел принципиальной разницы между описанием того, что Вы назвали фактом, в предложенной Вами структуре и системной. Плохо смотрел? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 08.02.2006, 11:40 |
|
||
|
Модель данных по Тенцеру
|
|||
|---|---|---|---|
|
#18+
To Guest: "Если я правильно Вас понял, любое уважающее себя приложение должно иметь не только собственную модель данных, но и собственную метамодель? ;))" - imho да, без нее построить настраиваемую систему очень тяжело построить. Пример: 1. как вы будете строить механизм генерации проводок без метамодели (ведь только она может хранить инфу, в где лежат суммы, какие поля таблиц используются для хранения аналитических признаков) 2. чтобы интегрироваться не на уровне записей в бд, а на уровне бизнес-объектов тоже надо иметь их описание,иначе не построить схемы трансформации данных и др. 3. Без метамодели объектов будете все равно строить ее для обеспечения настраиваемого контроля доступа ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 08.02.2006, 11:47 |
|
||
|
Модель данных по Тенцеру
|
|||
|---|---|---|---|
|
#18+
> imho да, без нее построить настраиваемую систему очень тяжело построить. Позвольте Вам не поверить. > 1. как вы будете строить механизм генерации проводок без метамодели (ведь только она может хранить > инфу, в где лежат суммы, какие поля таблиц используются для хранения аналитических признаков) Уважаемый дон понимает разницу между конфигом приложения и метамоделью? > 2. чтобы интегрироваться не на уровне записей в бд, а на уровне бизнес-объектов Что такое бизнес-объекты? Что такое не-бизнес-объекты? > иначе не построить схемы трансформации данных и др. Я не успеваю следить за полетом Вашей мысли: какие данные куда Вы собрались трансформировать? > 3. Без метамодели объектов Что такое объект? Что такое метамодель объектов? > для обеспечения настраиваемого контроля доступа Нет. Row-level security в рамках реляционной модели строится на раз-два-три. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 08.02.2006, 12:45 |
|
||
|
Модель данных по Тенцеру
|
|||
|---|---|---|---|
|
#18+
1. Не верьте (но предоставьте пример АБС (автоматизированной банковской системы без метамодели)) 2. конфиг строится на основе данных метамодели 3. бизнес-объект - сделка, не-бизнес- туева хуча таблиц, ее описывающих 4. Данные собрался трансформировать в форматы сделок (а не таблиц) для внешних систем и принимать их (их данные тоже трансформировать) 5. ладно, метамодели классов объектов 6. row-level нах никому не надо вне привязки к конкретным бизнес-объектам:доступ к таблице abc мне не надо запрещать как админу приложения - мне надо защищать доступ к атрибуту цена закрытия котировки ЦБ. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 08.02.2006, 13:05 |
|
||
|
Модель данных по Тенцеру
|
|||
|---|---|---|---|
|
#18+
P.S. Метамодели замечательно используются в генераторах отчетов,обеспечивающих "общение пользователей в терминах предметной области".Пример:BusinessObject - там строятся так называемые Universe. Кстати, в OLAP, которые используют как хранилище РСУБД, тоже метамодели очень живенько применяют. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 08.02.2006, 13:44 |
|
||
|
Модель данных по Тенцеру
|
|||
|---|---|---|---|
|
#18+
> 1. Не верьте (но предоставьте пример АБС (автоматизированной > банковской системы без метамодели)) Это предложение работы? Не вижу бюджета проекта. > 2. конфиг строится на основе данных метамодели ;)) > 3. бизнес-объект - сделка, не-бизнес- туева хуча таблиц, ее описывающих Какая сделка? Это какой-то специфичный объект базы данных? Чем он отличается от обычных объектов? > 4. Данные собрался трансформировать в форматы сделок (а не таблиц) > для внешних систем и принимать их (их данные тоже трансформировать) Упс. Повторю вопрос относительно сделки. Дополню вопросом о формате сделки. Это тоже какой-то специфичный объект? > 5. ладно, метамодели классов объектов ;) Понятнее не стало. Какие метамодели каких классов каких объектов? Вы вообще о чем говорите? > 6. row-level нах никому не надо вне привязки к конкретным > бизнес-объектам: Из предыдущего текста я понял, что бизнес-объект - это сделка. Я правильно интерпретировал текст: "без привязки к сделкам row-level контроль доступа не имеет смысла"? Если правильно, то Вы ошибаетесь. ;)) > доступ к таблице abc мне не надо запрещать как админу приложения - мне > надо защищать доступ к атрибуту цена закрытия котировки ЦБ. Хм... ну, во-первых, доступ к таблице и row-level контроль - это как бы два разных уровня ограничения доступа. ;) Во-вторых, я не вижу ни одной проблемы "защиты доступа к атрибуту цена закрытия котировки ЦБ". ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 08.02.2006, 13:50 |
|
||
|
Модель данных по Тенцеру
|
|||
|---|---|---|---|
|
#18+
1. Как всегда отбазарились вопросами на вопросы 2. см. п.1, но... По поводу проводок: пусть мне надо сделать новую проводку, в которой сумма дебита-величина комиссии.Я выбираю из справочника объектов класс Сделка, в котором есть атрибут типа Сумма и подставляю его в "конфиг проводок".Если надо будет подставить другой атрибут для суммы проводки-выберу его опять из другого справочника. 3. см. п1 4. см. п1 5. лозунг - пример в студию 6. пример плиз. Пусть я тупой админ и хочу закрыть доступ к какому-либо параметру класса (класс представлен множеством таблиц) по какому-либо условию, ну пусть, например, за 12 число сего месяца (row-level) - как мне в интерфейсе не имея метамодели этого самого класса выбрать его атрибут? Итого: по п.2 и п. 6 - одной метамоделью предметной области убиваем вопрос настраиваемой генерации проводок, настраиваемого контроля доступа и,по моему предыдущему сообщению,еще и генератор отчетов "в терминах предметной области". А что можете предложить Вы?! :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 08.02.2006, 14:08 |
|
||
|
Модель данных по Тенцеру
|
|||
|---|---|---|---|
|
#18+
А!... у каждого класса своя метамодель... я то думал, что метамодель у всех классов одна (эта метамодель так и называется - "класс")... но вообще то согласен - приставка "мета" звучит красиво - тут не постпоришь :). А ваще бы Вы сореинтировались бы на терминах:)..... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 08.02.2006, 14:15 |
|
||
|
Модель данных по Тенцеру
|
|||
|---|---|---|---|
|
#18+
Я, по-моему, очень четко выразился, что нужна "метамодель предметной области". P.S. Слишком быстро пробегали ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 08.02.2006, 14:25 |
|
||
|
Модель данных по Тенцеру
|
|||
|---|---|---|---|
|
#18+
guest_20040621> Вот минимальная структура с помощью которой можно описать все. "Все" в смысле все, что отвечает Вашим задачам? Или вообще любую структуру? ;) Думаю можно описать и хранить любые объекты и отношения. Этой структуры должна хватит. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 08.02.2006, 14:36 |
|
||
|
Модель данных по Тенцеру
|
|||
|---|---|---|---|
|
#18+
> 1. Как всегда отбазарились вопросами на вопросы Не "отбазарился", а задал дополнительные вопросы. В данном случае - потому, что в Вашей голове - абсолютная каша. > 2. см. п.1, но... Вы не понимаете очевидной разницы между конфигом и метамоделью. > 5. лозунг - пример в студию Какой лозунг? Пример чего? > 6. пример плиз. Класс сильно вряд ли имеет метамодель. ;) Модель - да. Вообще у вас смешались в кучу кони, люди: откуда-то вдруг интерфейсы появились, параметры класса. Что есть параметры класса? Атрибуты? Или очередная непонятная характеристика? Что есть интерфейс? Откуда и какие вдруг возникли проблемы с 12 числом? > одной метамоделью предметной области Поподробнее, пожалуйста: что это за метамодель предметной области? И представить себе не мог, что такие существуют. Ага, кажется, догадался: Вы неправильно понимаете и используете термины "модель" и "метамодель". ;)) > А что можете предложить Вы?! Непосредственно Вам - пожалуйста, перестаньте путать модель с метамоделью. А вообще о своем предложении я уже писал: метамодель должна быть стандартной. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 08.02.2006, 14:37 |
|
||
|
Модель данных по Тенцеру
|
|||
|---|---|---|---|
|
#18+
> Думаю можно описать и хранить любые объекты и отношения. > Этой структуры должна хватит. ОК, пусть так. А насколько удобно это будет делать? Давайте предположим, что мы храним xml файл. Тогда в Вашей структуре данных мы должны: 1. сначала описать соответствующую метамодель, 2. в терминах этой метамодели описать модель, 3. в терминах модели описать файл. Imho три уровня абстракции в одной структуре данных - многовато. ;) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 08.02.2006, 14:48 |
|
||
|
Модель данных по Тенцеру
|
|||
|---|---|---|---|
|
#18+
Флейм про мета не от разных точек отсчета? Shtock : Предметная область --> Данные=модель ПрО --> Словарь данных = метамодель ПрО. guest_20040621 : Данные --> Модель данных --> Метамодель данных. Видимо, Shtock.Метамодель ПрО ~ guest_20040621.Модель данных ~ ModelR.Словарь данных Так что я насчет метамодели данных я ничего не утверждал и кстати редко видел. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 08.02.2006, 14:51 |
|
||
|
Модель данных по Тенцеру
|
|||
|---|---|---|---|
|
#18+
> Флейм про мета не от разных точек отсчета? По-видимому, так и есть. > Так что я насчет метамодели данных я ничего не утверждал и кстати редко > видел. Вы писали как-то о MOF (не в этом треде), из чего я сделал вывод, что контекст обсуждения Вам понятен. ОК, вопросы снимаются, ответы на них очевидны, если Вы говорите о модели, а не о метамодели. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 08.02.2006, 15:02 |
|
||
|
Модель данных по Тенцеру
|
|||
|---|---|---|---|
|
#18+
Есть RDBMS и есть язык SQL, что мешает обсуждать конкретные декларации (которые лучше предварительно прогонять через конкретную СУБД)? В таком варианте было бы гораздо меньше тумана, особенно, если SQ-декларации снабжены комментариями, из которых следует, где модель,где метамодель,где остальное. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 08.02.2006, 15:02 |
|
||
|
Модель данных по Тенцеру
|
|||
|---|---|---|---|
|
#18+
guest_20040621> Думаю можно описать и хранить любые объекты и отношения. > Этой структуры должна хватит. ОК, пусть так. А насколько удобно это будет делать? Давайте предположим, что мы храним xml файл. Тогда в Вашей структуре данных мы должны: 1. сначала описать соответствующую метамодель, 2. в терминах этой метамодели описать модель, 3. в терминах модели описать файл. Imho три уровня абстракции в одной структуре данных - многовато. ;) Я думал про минимальную структуру. Можно как и было - объекты и отношения развести. А сгенерировать для каждого случая свое описание и хранилище - какая выгода. Лучше один раз разобраться механизмом навигации и компановки и забыть. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 08.02.2006, 15:05 |
|
||
|
Модель данных по Тенцеру
|
|||
|---|---|---|---|
|
#18+
Спасибо,ModelR: привели к общему знаменателю.Теперь надо объяснить,что без нее в серьезных вещах практически никак (примеры я уже привел),только почему-то они ряд людей не убеждают. P.S. Умение развести флейм - суть поведения на форуме ряда людей. To Guest: 1.Вопрос к делу не относился (при чем тут бюджет проекта и реальные системы), хотя я уже заметил,что все,что сделано не Вами уже изначально неправильно 2.конфиг без модели предметной области?Все зашить в код?! Ню-ню... 3. 12 - просто для балды число 4.пусть параметры класса будут атрибутами 5.интерфейс-в смысле междумордия приложения,GUI 6. Предложения по поводу настраиваемового приложения конкретно в плане настроек проводок (конфига), контроля доступа, генераторов отчетов в "терминах предметной области" P.S.Интересно,когда подеремся... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 08.02.2006, 15:19 |
|
||
|
Модель данных по Тенцеру
|
|||
|---|---|---|---|
|
#18+
> Теперь надо объяснить,что без нее в серьезных вещах практически никак > (примеры я уже привел) Без чего "без нее", уточните, пожалуйста. ;)) > Умение развести флейм - суть поведения на форуме ряда людей. ;) Согласитесь, я меньше всего виноват в том, что Ваша терминология отличается от общепринятой, правда? И абсолютно не виноват в том, что для того, чтобы это выяснить, понадобилась страница обсуждения. > 2.конфиг без модели предметной области?Все зашить в код?! Ню-ню... Ага, то есть мы уже о модели говорим. ;) Хорошо. Зачем "зашить в код"? Храните конфиги отдельно, как и следует это делать. > 3. 12 - просто для балды число Да я понял, что от балды. Я не знаю, что у Вас за пупер-мега-приложение, которое не позволяет делать элементарных вещей. Традиционная модель ограничения доступа: интерфейс, объекты бд, row-level. Проще всего на row-level сделать комбинированный доступ: (rwe + acl). Все. Никаких 12 чисел. Ничего запредельного. Хотите реального контроля доступа - почитайте про контекст безопасности (на примере хотя бы SELinux). Штука интересная, но для практической реализации жутко геморройная. > 4.пусть параметры класса будут атрибутами Давайте окончательно определимся: если Вы говорите об объектах бд, то там нет никаких классов. Если используете какую-то другую парадигму, напишите об этом явным образом. > 5.интерфейс-в смысле междумордия приложения,GUI Imho два подхода. Самый простой я уже описал выше. > 6. Предложения по поводу настраиваемового приложения конкретно в > плане настроек проводок (конфига), контроля доступа, генераторов > отчетов в "терминах предметной области" Формат конфигов - дело десятое, контроль доступа - традиционный. Если хотите отчеты нормального вида - опишите и используйте семантическую модель. В чем проблема? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 08.02.2006, 15:46 |
|
||
|
Модель данных по Тенцеру
|
|||
|---|---|---|---|
|
#18+
Programmer_OrtodoxЕсть RDBMS и есть язык SQL, что мешает обсуждать конкретные декларации (которые лучше предварительно прогонять через конкретную СУБД)? В таком варианте было бы гораздо меньше тумана, особенно, если SQ-декларации снабжены комментариями, из которых следует, где модель,где метамодель,где остальное. Интересно, через какую СУБД можно пропустить такой внешний ключ: Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. 24. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 08.02.2006, 15:54 |
|
||
|
Модель данных по Тенцеру
|
|||
|---|---|---|---|
|
#18+
Достаточно придерживаться ANSI ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 08.02.2006, 16:02 |
|
||
|
Модель данных по Тенцеру
|
|||
|---|---|---|---|
|
#18+
Е-мое,Вам никак не угодить. :) Что такое "семантическая модель" и почему на ее основе не сделать контроль доступа и мои любимые конфиги (конкретный пример про проводки-зачем делать отдельный конфиг по суммам проводок ,если в качестве их источников можно использовать в моем понятии "модель предметной области" или "семантическую модель" или какую-либо другую)? По поводу доступа (я как смотрю, это и Ваша и моя любимая тема):ну зачем админу приложения объекты БД (в моем понятии это таблицы, процедуры) (если Вы посмотрите на любую систему контроля доступа - она же всегда в терминах предметной области).Так зачем ее отдельно хранить то:я это в толк взять не могу!!! ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 08.02.2006, 16:07 |
|
||
|
Модель данных по Тенцеру
|
|||
|---|---|---|---|
|
#18+
> Что такое "семантическая модель" Имелась в виду онтологическая модель, извините. > почему на ее основе не сделать контроль доступа Потому что она решает абсолютно другие задачи. Вообще говоря, контроль доступа на основе онтологической модели возможен, но грамотная реализация - сложновата: в метамодели необходимо реализовать и стереотипы, и профили моделей. > зачем делать отдельный конфиг по суммам проводок А почему Вы меня об этом спрашиваете? Я утверждал, что конфиг никак не обязан быть связан с _метамоделью_. Как Вы будете конфигурировать Ваше приложение - это вопрос личных предпочтений и безопасности. > зачем админу приложения объекты БД Правильно, низачем. Я бы удивился, если бы узнал, что у Вас админ занимается вопросами ограничения доступа. > на любую систему контроля доступа - она же всегда в терминах > предметной области Не любая. Открываю умную книжку под названием "UNIX. Руководство системного администратора" и вижу, чтобы контекст прав - объекты файловой системы. Которые как бы никак не связаны с предметной областью. ;) В реальных приложениях целесообразно использовать аналогичный подход. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 08.02.2006, 16:54 |
|
||
|
Модель данных по Тенцеру
|
|||
|---|---|---|---|
|
#18+
ОДной из задач UNIX является работа с файлами-работа с файлами -предметная область контроля доступа. Я работаю в банковской области:работа со сделками-предметная область-следовательно ограничения на уровне атрибутов сделок и операций с ними. Под админом имеется в виду прикладной админ системы (а не БД или сети). Ладно, заканчиваю флейм,а то от (супер-полиндром вышел) исходной темы как всегда ушли. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 08.02.2006, 17:05 |
|
||
|
Модель данных по Тенцеру
|
|||
|---|---|---|---|
|
#18+
Сахават Юсифов guest_20040621> Думаю можно описать и хранить любые объекты и отношения. > Этой структуры должна хватит. ОК, пусть так. А насколько удобно это будет делать? Давайте предположим, что мы храним xml файл. Тогда в Вашей структуре данных мы должны: 1. сначала описать соответствующую метамодель, 2. в терминах этой метамодели описать модель, 3. в терминах модели описать файл. Imho три уровня абстракции в одной структуре данных - многовато. ;) Я думал про минимальную структуру. Можно как и было - объекты и отношения развести. А сгенерировать для каждого случая свое описание и хранилище - какая выгода. Лучше один раз разобраться механизмом навигации и компановки и забыть. Ну, Вы согласны или нет? А то мне работать надо. :) Жду Вашей оценки. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 08.02.2006, 17:22 |
|
||
|
Модель данных по Тенцеру
|
|||
|---|---|---|---|
|
#18+
> ОДной из задач UNIX является работа с файлами-работа с файлами > -предметная область контроля доступа. Нет. В Unix практически всё - файлы, процессы, устройства и пр. - объекты файловой системы. И доступ к ним контролируется строго определенным образом. Независимо от того, чем занимаются пользователи сервера. ;) > предметная область-следовательно ограничения на уровне атрибутов > сделок и операций с ними. Нижний уровень контроля доступа - это элементарные объекты. Если речь идет о базе данных - проще всего говорить о row-level ограничениях (вообще говоря, никто нигде не определял элементарный объект; просто сложилось так, что row-level довольно просто организовать). Все остальные ограничения на нижнем уровне можно построить комбинацией базовых row-level ограничений. В Вашем приложении ограничения на нижнем уровне отсутствуют, - но это не значит, что их там быть не может. ;) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 08.02.2006, 17:24 |
|
||
|
Модель данных по Тенцеру
|
|||
|---|---|---|---|
|
#18+
> Ну, Вы согласны или нет? Как минимальный набор сущностей - вполне возможно; у меня никогда не было такой задачи (построить структуру данных с минимальным набором сущностей и связей), так что ничего более конкретного сказать не могу. А если абстрактно - то представляется довольно сложной задачей упаковывать и извлекать из такой структуры данные. В этом отношении Ваша предыдущая схема мне кажется более удобной. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 08.02.2006, 17:32 |
|
||
|
Модель данных по Тенцеру
|
|||
|---|---|---|---|
|
#18+
guest_20040621> Ну, Вы согласны или нет? Как минимальный набор сущностей - вполне возможно; у меня никогда не было такой задачи (построить структуру данных с минимальным набором сущностей и связей), так что ничего более конкретного сказать не могу. А если абстрактно - то представляется довольно сложной задачей упаковывать и извлекать из такой структуры данные. В этом отношении Ваша предыдущая схема мне кажется более удобной. Спасибо. Попробую так и эдак. Небось что-нибудь получится. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 08.02.2006, 17:56 |
|
||
|
Модель данных по Тенцеру
|
|||
|---|---|---|---|
|
#18+
alter view add foreign key Programmer_OrtodoxДостаточно придерживаться ANSIВ какой СУБД? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 09.02.2006, 11:15 |
|
||
|
Модель данных по Тенцеру
|
|||
|---|---|---|---|
|
#18+
ModelRalter view add foreign key Programmer_OrtodoxДостаточно придерживаться ANSIВ какой СУБД? Не слишком экзотической, чтобы участники форума могли проверить. Один из возможных кандидатов, Firebird, - бесплатен, поддерживает ANSI. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 09.02.2006, 12:26 |
|
||
|
Модель данных по Тенцеру
|
|||
|---|---|---|---|
|
#18+
Programmer_OrtodoxНе слишком экзотической, чтобы участники форума могли проверить. Один из возможных кандидатов, Firebird, - бесплатен, поддерживает ANSI.Под рукой есть не слишком экзотический Oracle 9i, но даже в Oracle 10g2: View Constraints Oracle does not enforce view constraints. However, operations on views are subject to the integrity constraints defined on the underlying base tables. This means that you can enforce constraints on views through constraints on base tables. Notes on View Constraints View constraints are a subset of table constraints and are subject to the following restrictions: You can specify only unique, primary key, and foreign key constraints on views. However, you can define the view using the WITH CHECK OPTION clause, which is equivalent to specifying a check constraint for the view. View constraints are supported only in DISABLE NOVALIDATE mode. You cannot specify any other mode. You must specify the keyword DISABLE when you declare the view constraint. You need not specify NOVALIDATE explicitly, as it is the default.Т.е. только планировщику помогает, целостности - нет. В Firebird не так? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 09.02.2006, 13:34 |
|
||
|
Модель данных по Тенцеру
|
|||
|---|---|---|---|
|
#18+
Продекларированные в рамках выбранной СУБД фантазии должны быть настолько буйными, чтобы они могли быть откомпилированы. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 09.02.2006, 13:59 |
|
||
|
Модель данных по Тенцеру
|
|||
|---|---|---|---|
|
#18+
Up (Все в ожидании, кады вже guest_20040621 перестанет бухтеть и надувацца и поделицца таки сокровенным знанием. А хотя бы схемки для размещения XML) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 10.02.2006, 11:56 |
|
||
|
Модель данных по Тенцеру
|
|||
|---|---|---|---|
|
#18+
У меня есть смутные подозрения, что реляционную базу любого уровня сложности можно построить на одной таблице ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 10.02.2006, 18:48 |
|
||
|
Модель данных по Тенцеру
|
|||
|---|---|---|---|
|
#18+
Cat2У меня есть смутные подозрения, что реляционную базу любого уровня сложности можно построить на одной таблице Запросто. :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 10.02.2006, 22:25 |
|
||
|
Модель данных по Тенцеру
|
|||
|---|---|---|---|
|
#18+
Cat2У меня есть смутные подозрения, что реляционную базу любого уровня сложности можно построить на одной таблице И сколько у Вас полей (минимум)? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.02.2006, 20:48 |
|
||
|
Модель данных по Тенцеру
|
|||
|---|---|---|---|
|
#18+
Сахават Юсифов Код "таблицы" Код поля Тип поля Размерность Значение Строгих доказательств не имею. Нутром чую ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.02.2006, 21:56 |
|
||
|
Модель данных по Тенцеру
|
|||
|---|---|---|---|
|
#18+
Cat2Сахават Юсифов Код "таблицы" Код поля Тип поля Размерность Значение Строгих доказательств не имею. Нутром чую Что за Код "таблицы"? Отношение не зададите! ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.02.2006, 23:45 |
|
||
|
Модель данных по Тенцеру
|
|||
|---|---|---|---|
|
#18+
Сахават Юсифов. Вот, настырный. Любую таблицу можно преобразовать в вертикаль. Код поля Тип поля Размерность Значение Надеюсь, Вы с этим согласны? Это же "по Тенцеру" Для различия между разными сущностями нужно добавить только одно поле - которое я обозвал - код "Таблицы" ============ Этот тип баз будет называться "модель по cat2"! ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 12.02.2006, 00:15 |
|
||
|
Модель данных по Тенцеру
|
|||
|---|---|---|---|
|
#18+
Cat2Сахават Юсифов. Вот, настырный. Любую таблицу можно преобразовать в вертикаль. Код поля Тип поля Размерность Значение Надеюсь, Вы с этим согласны? Это же "по Тенцеру" Для различия между разными сущностями нужно добавить только одно поле - которое я обозвал - код "Таблицы" ============ Этот тип баз будет называться "модель по cat2"! Эээээ! Нет никаких других сущностей! Одна ТАБЛИЦА, много сущностей и много отношений в этой таблице. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 12.02.2006, 00:19 |
|
||
|
Модель данных по Тенцеру
|
|||
|---|---|---|---|
|
#18+
Cat2Сахават Юсифов Код "таблицы" Код поля Тип поля Размерность Значение Строгих доказательств не имею. Нутром чую Упушшение на блюда ю у васт: Кот "таблицы" --сучьность Кот записи --экземпляр сучности Кот поля Тип поля Размерность Значение ЗЗЫ однако тут не влезають ограничения . Можно какнешнешна на триггерах по Кот таблитцы накручивать. Но сложно. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 12.02.2006, 10:43 |
|
||
|
Модель данных по Тенцеру
|
|||
|---|---|---|---|
|
#18+
43210 Cat2Сахават Юсифов Код "таблицы" Код поля Тип поля Размерность Значение Строгих доказательств не имею. Нутром чую Упушшение на блюда ю у васт: Кот "таблицы" --сучьность Кот записи --экземпляр сучности Кот поля Тип поля Размерность Значение ЗЗЫ однако тут не влезають ограничения . Можно какнешнешна на триггерах по Кот таблитцы накручивать. Но сложно. Какие еще сучьности? Есть объект. У него есть список свойств. Свойства имеют список значений (хронологических). Получается дерево. Куча таких объектов дает граф (сеть). Что бы указать отношения между объектами создаем объект (отношение) и в свойствах этого объекта перечисляем объекты - субъекты отношения и собственные своства отношения. XML, блин. :) Если на нужна коллекция объектов с одинаковыми (или пересечение множества свойств) (Ваша сучьность), то выбираем все соответствующие объекты. Для идентификации отношений вводим тип объект или значение свойства=NULL (а можно по деревям лазить и ничего не вводить). Для целостности надо вводить коолекции "объект,тип" и "тип" и включить в типы "объект" и "свойство". ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 12.02.2006, 11:06 |
|
||
|
Модель данных по Тенцеру
|
|||
|---|---|---|---|
|
#18+
Сахават Юсифов >>Эээээ! Нет никаких других сущностей! Одна ТАБЛИЦА, много сущностей и много отношений в этой таблице Я это и имею ввиду. Слово "сущности" мною было употреблено в смысле - существующие в реальном мире множества данных, которые должны учитываться в базе. Для перевода любой базы в однотабличную форму мы делаем ее котизацию. 1. Сначала переводим все таблицы в вертикальное представление (с) (на всякий случай. А то пристанут, что нет такого термина!) 2. А потом сливаем их в одну таблицу, вводя еще одно поле для идентификации таблицы. 43210. В Правилах не описано, каким образом должна обеспечиваться целостность данных. Можно и на тригерах. Сахават Юсифов 2 >>Какие еще сучьности? ... Получается дерево. Вы правы - дерево получается. Даже не дерево, а биоценоз. То, от чего и уводит реляционная модель. Которая, на мой взгляд, является разумным компромисом между объективно существующими сетевыми связями* объектов реального мира и удобством их представления для обработки в компьютере. ===== * Под сетевыми связями я понимаю, в меру своего умения читать книги, наличие множественного наследования ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 12.02.2006, 12:03 |
|
||
|
Модель данных по Тенцеру
|
|||
|---|---|---|---|
|
#18+
Cat2Вы правы - дерево получается. Даже не дерево, а биоценоз. То, от чего и уводит реляционная модель. Которая, на мой взгляд, является разумным компромисом между объективно существующими сетевыми связями* объектов реального мира и удобством их представления для обработки в компьютере. ===== * Под сетевыми связями я понимаю, в меру своего умения читать книги, наличие множественного наследования Ладно, консенсус! А то будем до посинения как ЧАЛ сотоварищи. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 12.02.2006, 12:53 |
|
||
|
Модель данных по Тенцеру
|
|||
|---|---|---|---|
|
#18+
:) Если таблица одна, то зачем каждый раз писать select ... from TABLE where Сущность='C1' ... ? На то и СУБД, что бы упрощать жизнь, введем сокращение : select_ ... from C1 ... Опа, опять много таблиц получилось... :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.02.2006, 09:43 |
|
||
|
Модель данных по Тенцеру
|
|||
|---|---|---|---|
|
#18+
Cat2У меня есть смутные подозрения, что реляционную базу любого уровня сложности можно построить на одной таблице лучше на двух - объекты и атрибуты ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.02.2006, 11:28 |
|
||
|
Модель данных по Тенцеру
|
|||
|---|---|---|---|
|
#18+
43210 Кот "таблицы" --сучьность Кот записи --экземпляр сучности Кот поля Тип поля Размерность Значение Тип поля и Размерность не нужны они д.б. в метаописании ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.02.2006, 11:43 |
|
||
|
Модель данных по Тенцеру
|
|||
|---|---|---|---|
|
#18+
мод 43210 Кот "таблицы" --сучьность Кот записи --экземпляр сучности Кот поля Тип поля Размерность Значение Тип поля и Размерность не нужны они д.б. в метаописании гм. тут люди договорились, шо никакого мета и т.п. описания не нада. т.е. не нада "кот записи" различать с "кот таблицы" - т.к. всякая сучность есть (уно)экземплярна. а если нужны (их) каллекции, то они (каллекции) храняцца тутжа как сучности "каллекция". Т.е. неча толкать нас в сложности многотабличных мета и т.п. моделей. нет никаких схем и структур. все лежит в наборе значений свойств (в первородном виде), а не в двойственностях "структуры" - "значения". ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.02.2006, 12:33 |
|
||
|
Модель данных по Тенцеру
|
|||
|---|---|---|---|
|
#18+
Cat2У меня есть смутные подозрения, что реляционную базу любого уровня сложности можно построить на одной таблице Можно. Только всю логику придётся вынести в приложение... А лучше в отдельную библиотечку. И сделать логику настраиваемой. И однажды эта библиотечка дорастёт до СУБД над СУБД. И тогда главное не брить полученное бритвой Оккама :) . По-моему, модель Тенцера и другие вариации на тему EAV нужно использовать только там, где они действительно нужны. Т.е. если есть что-то, список свойств чего часто и активно изменяется и/или для чего необходимо хранить историческую информацию и/или что может хитрым образом связываться с другими подобными объектами, быть родителем/ребёнком/составляющим, наследовать и т.д. то такая модель хранения себя оправдывает, а её применение для хранения всего и вся без разбора неминуемо приводит к изобретению велосипеда. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.02.2006, 12:37 |
|
||
|
Модель данных по Тенцеру
|
|||
|---|---|---|---|
|
#18+
ModelR wrote: > :) > Если таблица одна, то зачем каждый раз писать > select ... from TABLE where Сущность='C1' ... ? > > На то и СУБД, что бы упрощать жизнь, введем сокращение : > select_ ... from C1 ... > > Опа, опять много таблиц получилось... > :) а Вы в качестве сокращения используйте view - таблиц будет мало. Зато view - вагон! продавать можно :-) -- ------------------------- There's no silver bullet! Posted via ActualForum NNTP Server 1.3 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.02.2006, 12:43 |
|
||
|
Модель данных по Тенцеру
|
|||
|---|---|---|---|
|
#18+
[quot 4321гм. тут люди договорились, шо никакого мета и т.п. описания не нада.[/quot] так не пойдет. где-то надо хранить схему "логической" БД. метаописание решает многие проблемы. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.02.2006, 12:52 |
|
||
|
Модель данных по Тенцеру
|
|||
|---|---|---|---|
|
#18+
AlexTheRaven По-моему, модель Тенцера и другие вариации на тему EAV нужно использовать только там, где они действительно нужны. Т.е. если есть что-то, список свойств чего часто и активно изменяется и/или для чего необходимо хранить историческую информацию и/или что может хитрым образом связываться с другими подобными объектами, быть родителем/ребёнком/составляющим, наследовать и т.д. т.е. почти всегда :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.02.2006, 12:55 |
|
||
|
Модель данных по Тенцеру
|
|||
|---|---|---|---|
|
#18+
мод так не пойдет. где-то надо хранить схему "логической" БД. метаописание решает многие проблемы."решает" и "нада" вещи весьма далекие друх от друха. "решает" => "было бы удобно" .... "нада" => "явлеецца необходимым". в данном случае речь (не моя), (с разъяснением мне от с.ю. там выше по топику) в частности о том, что ничто не мешает и схему опписать тут же. в виде тех же записей той же таблицы. правда думаю за подробностями лехше отправиться к шуклину - видимо так построен его моск (без таблиц, а просто как набор A-c->B, причем связи -c-> таки у него кажется явно выделены в особые "объекты"). ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.02.2006, 13:25 |
|
||
|
Модель данных по Тенцеру
|
|||
|---|---|---|---|
|
#18+
модт.е. почти всегда :) Просто у вас хорошие задачи! А у меня скорее изредка... хотя я стараюсь всё делать как можно проще. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.02.2006, 12:03 |
|
||
|
Модель данных по Тенцеру
|
|||
|---|---|---|---|
|
#18+
У нас в течении 5 лет структура базы неоднократно менялась, очень сложно поддерживать (особенно импорт данных). Мы самостоятельно пришли к структуре, аналогичной модели Тенцера. В документе СРАВНИТЕЛЬНЫЙ АНАЛИЗ НЕКОТОРЫХ МЕТОДОВ O – R-ПРЕОБРАЗОВАНИЯ в пункте 5 приводится актуальная проблема назначения атрибутов связи. Вопрос: как вы ее решали? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.11.2009, 14:32 |
|
||
|
Модель данных по Тенцеру
|
|||
|---|---|---|---|
|
#18+
HoneyУ нас в течении 5 лет структура базы неоднократно менялась, очень сложно поддерживать (особенно импорт данных). Мы самостоятельно пришли к структуре, аналогичной модели Тенцера. В документе СРАВНИТЕЛЬНЫЙ АНАЛИЗ НЕКОТОРЫХ МЕТОДОВ O – R-ПРЕОБРАЗОВАНИЯ в пункте 5 приводится актуальная проблема назначения атрибутов связи. Вопрос: как вы ее решали?вот это ты поднял тему! ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.11.2009, 15:23 |
|
||
|
|

start [/forum/topic.php?all=1&fid=32&tid=1542992]: |
0ms |
get settings: |
10ms |
get forum list: |
16ms |
check forum access: |
4ms |
check topic access: |
4ms |
track hit: |
203ms |
get topic data: |
12ms |
get forum data: |
3ms |
get page messages: |
159ms |
get tp. blocked users: |
2ms |
| others: | 248ms |
| total: | 661ms |

| 0 / 0 |
