|
|
|
Модель данных по Тенцеру
|
|||
|---|---|---|---|
|
#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 |
|
||
|
|

start [/forum/topic.php?fid=32&msg=33455754&tid=1542992]: |
0ms |
get settings: |
8ms |
get forum list: |
14ms |
check forum access: |
2ms |
check topic access: |
2ms |
track hit: |
172ms |
get topic data: |
9ms |
get forum data: |
2ms |
get page messages: |
58ms |
get tp. blocked users: |
1ms |
| others: | 244ms |
| total: | 512ms |

| 0 / 0 |
