|
|
|
Справочники - вместе или отдельно
|
|||
|---|---|---|---|
|
#18+
Klick Универсальный справочник на все и вся.. Есть один мощный аргумент в пользу этой идеи, но только он зависит от Вашего "боевого начала". В 93 году, я внедрял системы бух_учета, где задача универсальности была решена в полном объеме. (1С это и не снилось). Структура БД была описана в журналах БД, и при добавлении объектам новых атрибутов - все само получалось. Гибко и мощно. Но, это достигнуо исключительно за счет того, что интерфейсы ввода - они тоже ...на лету создавались... Все экранный формы ввода - все имели одинаковый вид. Где просто, в виде списка (в одну или в две колонки) предъявлялось Имя поля по русски........Поле ввода значения, примерно вот так: Код: plaintext 1. 2. 3. При этом, в этом интерфейсе, отразились ВСЕ виды бухгалтерких документов по ВСЕМ операциям учета, существующие в бухгатерии огромного завода... При этом, был обеспечен Интерфейс Массового Ввода (когда, например данные по зарплате (по виду начисления) цеха с 1000 рабочими можно было вогнать буквально за очень короткое время. Все отчеты системы - имели также, универсальной описание в журнале БД, и сами все получались. Понятно, что разработчкии этой системы потратили много труда для системного программирования, когда, например, все справочники очень удобно отражались всего через ОДНУ форму представления....ну понимаете, они ведь все там пикселы (символы),...длины полей... просчитывали на лету....и на лету...все отражали... Увы, наши тулзы визуального проектирования не любят таких фишек. Но я бы рискнул. В частности, я недавно применил стратегию - когда все системные вещи (секьюрити) например - это всего одно Деревянное табло, а прикладное - оно все фиксированное. Но прикладное - тоже можно развиваить в универсал - путем гибкой надстройки (при желании). . ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 12.03.2004, 15:47 |
|
||
|
Справочники - вместе или отдельно
|
|||
|---|---|---|---|
|
#18+
ИМХО - справочники(да и не только) можно хранить в четырех таблицах - (класс, поля класса, экземпляр класса, значения полей для экземпляра). Всегда лучше править данные, чем метаданные(если разработка перманентная). Скорость работы на такой структуре - приемлемая. Гибкость - высокая. А возможность удаленного сопровождения может перевесить все остальные аргументы. Опять же клиентские места генерируются на лету, прозрачная репликация и ещё много вкусных плюшек. Вещь очень жизненная, хоть и далеко не новая. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.03.2004, 13:54 |
|
||
|
Справочники - вместе или отдельно
|
|||
|---|---|---|---|
|
#18+
> ИМХО - справочники(да и не только) можно хранить в четырех таблицах - (класс, > поля класса, экземпляр класса, значения полей для экземпляра). > Всегда лучше > править данные, чем метаданные(если разработка перманентная). Скорость > работы на такой структуре - приемлемая. Гибкость - высокая. Уважаемый дон приведет пример и цифры в подкрепление тезиса о приемлемости скорости работы такой структуры? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.03.2004, 09:44 |
|
||
|
Справочники - вместе или отдельно
|
|||
|---|---|---|---|
|
#18+
Я говорил о следующих цифрах(текущий проект): классов~110, полей классов~450, экземпляров классов(объектов)~46500, полей классов~316400 При этом имеется наследование в классах и хранится вся история изменений. Различных АРМов-10, клиентов-25, поток запросов весьма интесивный. Неужели лучше сделать 110 таблиц? И опять же ИМХО - универсальных решений не бывает, есть лишь удачные в определенных ситуациях паттерны проектирования. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.03.2004, 10:13 |
|
||
|
Справочники - вместе или отдельно
|
|||
|---|---|---|---|
|
#18+
> Я говорил о следующих цифрах(текущий проект): классов~110, полей > классов~450, экземпляров классов(объектов)~46500, полей классов~316400 > При этом имеется наследование в классах и хранится вся история изменений. > Различных АРМов-10, клиентов-25, поток запросов весьма интесивный. 25 клиентов - это хорошо. А что за ОС/СУБД? Если не секрет, как хранится история? Как организовано наследование? Если не лень, маленький пример одного справочника (подойдет на пальцах). > Неужели лучше сделать 110 таблиц? Смотря по задаче. > И опять же ИМХО - универсальных решений > не бывает, есть лишь удачные в определенных ситуациях паттерны > проектирования. Спору нет, согласен. С другой стороны, справочники - штука реюзабельная, поэтому здесь можно скорее говорить не об универсальности решения, а о предпочтениях разработчика. ;) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.03.2004, 15:56 |
|
||
|
Справочники - вместе или отдельно
|
|||
|---|---|---|---|
|
#18+
Секретов нет - Yaffil(Classic)/W2000. А пример ... могу скриншот выслать. Наследование - деревянное. Вся логика наследования и сохранения истории - триггерная(принцип неизменности ИК и создание новой записи как архивной, пометка удаленной записи). Возможны взаимные ссылки, отношения много-ко-многим. Все не раз описано в статьях. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.03.2004, 18:10 |
|
||
|
Справочники - вместе или отдельно
|
|||
|---|---|---|---|
|
#18+
Хочу поделится своей структурой справочников: Я использую объектный стиль проектирования БД Что такое самы простой справочник? Это ID и Name, сделайте для этого таблицу: create table Objects ( OID int not null identity(1,1), Name varchar(128), primary key clustered ( OID ) ) go Несколько справочников у вас уже будет. Чтобы их различать введите поле типизации: create table Objects ( OID int not null identity(1,1), Name varchar(128), Class varchar(32) not null default ('DBObject'), primary key clustered ( OID ) ) go Если в вашем справочнике есть доп. атрибуты сделайте их в доп. таблице (то бишь наследование :) create table Clients ( OID int not null, Address varchar(255), primary key clustered ( OID ) ) go Добавление записей в простой справочник create procedure DBObject_Create @OID int output @Name varchar(128), @Class varchar(32) as insert into Objects ( Name, Class ) select @Name, @Class select @OID = @@identity go Добавление записей в справочник клиентов create procedure DBOClient_Create @OID int output, @Name varchar(128), @Class varchar(32), @Address varchar(255) as exec DBObject_Create @OID output, @Name, @Class insert into Clients select @OID, @Address go выборка данных для класса 'DBObject' select * from Objects where Class = 'DBObject' выборка данных для класса 'DBOClient' select * from Objects o inner join Clients c on c.OID = o.OID and o.Class = 'DBOClient' и так далее. Механизм наследования понятен? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.03.2004, 18:34 |
|
||
|
Справочники - вместе или отдельно
|
|||
|---|---|---|---|
|
#18+
> А пример ... могу скриншот выслать. Спасибо, не нужно. ;) > Наследование - деревянное. Ага. Значит, еще и иерархия для объектов есть. А если захочется классификатор справочников (проще два раза щелкнуть мышью, чем листать список) - плюс еще пара таблиц. ;) Плюс связи (если они множественные). ;) Конечно, таблиц не 110, но imho получается не так просто, как хотелось бы. О чем, собственно, и речь. В общем, как правильно замечено, [цитата] универсальных решений не бывает, есть лишь удачные в определенных ситуациях паттерны проектирования [конец цитаты]. ;) > Вся логика наследования и сохранения истории - триггерная (принцип > неизменности ИК и создание новой записи как архивной, пометка удаленной > записи). Понятно. Вполне себе продакшн решение. Таймер есть или временные метки произвольны (или другая логика истории)? Какая security model используется? > Все не раз описано в статьях. Это понятно. Только судя по _подавляющему большинству_ форумов, и Дейта не всякий потрудился прочесть, не говоря о большем. ;) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.03.2004, 22:15 |
|
||
|
Справочники - вместе или отдельно
|
|||
|---|---|---|---|
|
#18+
PostgreSQL userКонечно, таблиц не 110, но imho получается не так просто, как хотелось бы. Получается просто и таблиц именно 4, а не больше. PostgreSQL userТаймер есть или временные метки произвольны (или другая логика истории)? Какая security model используется? Временные метки, как вы понимаете, должны быть пользовательские и системные. А security model практически не используется в БД, только security ОС. Но только справочники тут не причем :-) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 24.03.2004, 10:05 |
|
||
|
Справочники - вместе или отдельно
|
|||
|---|---|---|---|
|
#18+
2Могун А не могли бы вы поподробнее описать вашу модель и выслать скриншоты на мыло : lopatinve@mail.ru ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 24.03.2004, 11:08 |
|
||
|
Справочники - вместе или отдельно
|
|||
|---|---|---|---|
|
#18+
> Получается просто и таблиц именно 4, а не больше. ОК, обошлись 4 таблицами - хорошо. Мне потребовалось бы больше. Собственно, к чему я речь вел (с примерами не получилось, классификация тоже, как выяснилось, не нужна, права на объекты раздавать не нужно - ну, на нет и суда нет): есть смысл объединять в одной структуре _однотипные_ справочники. Дешевле и логичнее [грустную историю про мухи и котлеты пересказывать не буду]. > Временные метки, как вы понимаете, должны быть пользовательские и системные. Откуда вдруг взялись пользовательские? У пользователей время течет отлично от системного (час за два)? Интересная постановка задачи. > А security model практически не используется в БД, только security ОС. Не понял, как это "практически не используется"? Т. е., здесь используется, а здесь рыбу заворачивали? ;) > Но только справочники тут не причем :-) Это только так кажется. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 24.03.2004, 17:37 |
|
||
|
Справочники - вместе или отдельно
|
|||
|---|---|---|---|
|
#18+
PostgreSQL userОткуда вдруг взялись пользовательские? У пользователей время течет отлично от системного (час за два)? Интересная постановка задачи. Мне непонятна ваша ирония... Пользовательская временная метка - это время наступления события с точки зрения пользователя. Системная - время, когда об этом стало известно системе(текущее системное). Простой пример - ставка НДС 18% вступила в действие с 01.01.2004 00:00:00. Если запись об этом была сделана заранее - это одно, если задним числом - требуется перерасчет. PostgreSQL user есть смысл объединять в одной структуре _однотипные_ справочники. Дешевле и логичнее Что по-вашему есть однотипные справочники? И что есть классификация? PostgreSQL userТ. е., здесь используется, а здесь рыбу заворачивали? ;) Смешно... Но в таком тоне диалога не получится. Изложите свои мысли понятнее. > Но только справочники тут не причем :-) Это только так кажется. А это вообще из области - догадайтесь-ка в каком кармане у меня фига - глубокомысленно... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 25.03.2004, 10:22 |
|
||
|
Справочники - вместе или отдельно
|
|||
|---|---|---|---|
|
#18+
> Пользовательская временная метка - это время наступления события с точки > зрения пользователя. Ага. Понятно. Несколько непривычная интерпретация, поэтому и возник вопрос. > Системная - время, когда об этом стало известно системе(текущее системное). В контексте вышенаписанного тоже понятно. > Что по-вашему есть однотипные справочники? И что есть классификация? Однотипные - описывающие близкие по смыслу сущности (единицы измерений, (экс-) территориальные единицы etc). Классификация... не знаю, какой синоним здесь уместен. Группировка сущностей по некоторым признакам? > Смешно... Рад, что повеселил. > Изложите свои мысли понятнее. По моему мнению, модель ограничения доступа либо используется, либо нет. Ни разу не сталкивался с реализацией "практически не используется". Почему и удивился. > А это вообще из области - догадайтесь-ка в каком кармане у меня фига - > глубокомысленно... ;) ОК, подробнее: если security model предполагает ограничения на уровне таблиц, то будет проблематично ограничить доступ пользователей к справочникам, если все они описаны в рамках одной структуры. Понятно, что это не единственно возможный вариант модели, но - один из самых простых. Поэтому не стал бы утверждать, что организация справочников и модель ограничения доступа независимы. Хотелось обратить внимание на то, что организация хранения справочных данных - это не только проблема технического характера. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 25.03.2004, 13:34 |
|
||
|
Справочники - вместе или отдельно
|
|||
|---|---|---|---|
|
#18+
У подхода одного справочника есть некоторые недостатки: 1) мы ослабляем контроль ссылочной целостности, т.к., например, вместо ссылки на физ. лицо можно поставить ссылку на организацию, и сервер нас за это не отругает. 2) Сложнее делать разграничение прав пользователей. Вместо этого, мне кажется можно использовать гибридный подход, т.е. базовые таблицы создавать отдельно, но давать возможность создавать свойства определяемые пользователем. Владимир ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 25.03.2004, 16:18 |
|
||
|
Справочники - вместе или отдельно
|
|||
|---|---|---|---|
|
#18+
immutable : это не недостатки системы, это недостатки программиста ссылочная целостность легко реализуется через специальный механизм, пример из практики: create procedure DBOThing_Delete_DBOMeasure @OID OID as declare @Name String select @Name = (select top 1 o.Name from Things t inner join Objects o on o.OID = t.OID where t.MeasureOID = @OID) if @Name is not null begin raiserror('Единица измерения ссылается на объект учета <%s>, 11, 1, @Name) return 1 end go Если пользователь попытается удалить Единицу измерения, то специальный движок вызовет все процедуры, где первый класс любой, а второй класс не выше DBOMesaure, подставляя туда свой идентификатор. Если хоть один облом произойдет, удаления не будет. Кроме того я сделал процедуру, которая сканирует все таблицы где есть поля типа OID (это тип от int, используется для идентификатора объекта) и есть значения удаляемого объекта. create procedure DBObject_CheckConstraints @OID OID as declare @Column sysname, @Table sysname, @CharOID String, @Count int select @CharOID = convert(varchar(32), @OID) delete DeletedObjs declare Walker cursor local fast_forward for select c.name, o.name from syscolumns c inner join systypes t on t.xusertype = c.xusertype and t.name = 'OID' inner join sysobjects o on o.id = c.id and (o.xtype = 'U' or o.xtype = 'V') where o.name <> 'Blocks' open Walker fetch next from Walker into @Column, @Table while(@@FETCH_STATUS <> -1) begin if(@@FETCH_STATUS <> -2) begin exec( 'insert into DeletedObjs select ' + @Column + ' from ' + @Table + ' where ' + @Column + ' = ' + @CharOID) select @Count = (select count(OID) from DeletedObjs) if @Count <> 0 begin raiserror('Нельзя удалить объект. На него есть ссылка в поле <%s> таблицы <%s>', 11, 1, @Column, @Table) return 1 end end fetch next from Walker into @Column, @Table end close Walker deallocate Walker go если осталась хоть одна ссылка, про которую забыли программисты, то система выругается, типа в таблице <> в поле <> есть ссылка ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 25.03.2004, 19:14 |
|
||
|
Справочники - вместе или отдельно
|
|||
|---|---|---|---|
|
#18+
Может конечно это недостатки программиста, но мне больше нравится _уже_ реализованная на уровне СУБД декларативная ссылочная целостность, которая надежнее рукописных процедур с использованием динамического SQL. Владимир ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 25.03.2004, 20:27 |
|
||
|
Справочники - вместе или отдельно
|
|||
|---|---|---|---|
|
#18+
immutableМожет конечно это недостатки программиста, но мне больше нравится _уже_ реализованная на уровне СУБД декларативная ссылочная целостность, которая надежнее рукописных процедур с использованием динамического SQL. Ну-ну, что-то вы запоёте, когда этих справочников станет больше ста... ------------------------------------------------------------------ когда я ем, я глух и нем, когда я пью, вообще дурной ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.03.2004, 11:18 |
|
||
|
Справочники - вместе или отдельно
|
|||
|---|---|---|---|
|
#18+
Код: plaintext 1. Есть еще минусы: 1. При разработки требуется создание администраторской утилиты для работы 2. и при проектировании скажем с использованием case средств, обычная реляционная модель значительно лучше читается, обеспечивается наглядность и простота восприятия для кодеров. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.03.2004, 13:03 |
|
||
|
Справочники - вместе или отдельно
|
|||
|---|---|---|---|
|
#18+
Могун Если у вас в какой-либо достаточно изолированной подсистеме будут использоваться сразу более 100 справочников - вы и так и так запоете :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.03.2004, 13:24 |
|
||
|
Справочники - вместе или отдельно
|
|||
|---|---|---|---|
|
#18+
> и при проектировании скажем с использованием case средств Хм... а что, есть вменяемые case средства для проектирования структуры базы данных? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.03.2004, 14:30 |
|
||
|
Справочники - вместе или отдельно
|
|||
|---|---|---|---|
|
#18+
>PostgreSQL user Это зависит от СУБД. Разные Case средства по разному адаптированы под них, вплоть до версий. Идеальных конечно нет (а жаль), но ручками то еще хуже, если документации не делать, так через пару месяцев, только по данным и будешь понимать что где лежит :), а если данные в одной куче... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.03.2004, 15:39 |
|
||
|
Справочники - вместе или отдельно
|
|||
|---|---|---|---|
|
#18+
> Это зависит от СУБД. Смотря по задаче. > Идеальных конечно нет Imho, приемлемых нет, не говоря об идеальных. > но ручками то еще хуже Да ну? Возможно, медленнее, но точно не хуже. > если документации не делать, так через пару месяцев, только по данным и > будешь понимать что где лежит :) Хм... уважаемый дон слышал о самодокументировании? ;) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.03.2004, 16:38 |
|
||
|
Справочники - вместе или отдельно
|
|||
|---|---|---|---|
|
#18+
По поводу case средств остаюсь при своем мнении. При проектировании их активно использую. Во всяком случае на начальном этапе разработки скорость разработки значительно выше. При сопровождении конечно их эффективность снижается, но надо учитывать еще тот факт, что при проектировании не приходится думать о диалекте SQL конкретной СУБД. PostgreSQL user Хм... уважаемый дон слышал о самодокументировании? ;) Не слышал, ссылочку киньте. Но как позвольте узанть оно(самодокументирование) будет протекать, если справочники будут создаваться в объектной модели, т.е. юзверями? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.03.2004, 17:26 |
|
||
|
Справочники - вместе или отдельно
|
|||
|---|---|---|---|
|
#18+
To Могун: А что я должен запеть? Если они такие одинаковые, то кто мне мешает их создать скриптом в CASE средстве? Приличные CASE позволяют использовать средства малой механизации,т.е. дают ползать VBScript'ом по своей объектной модели. To PostgreSQL user: Какими CASE средствами вы пользовались и чем конкретно они не устраивают? Владимир ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 31.03.2004, 11:39 |
|
||
|
Справочники - вместе или отдельно
|
|||
|---|---|---|---|
|
#18+
immutableА что я должен запеть? Если они такие одинаковые, то кто мне мешает их создать скриптом в CASE средстве? Приличные CASE позволяют использовать средства малой механизации,т.е. дают ползать VBScript'ом по своей объектной модели. Я имел ввиду вашу лебединую песню ПОСЛЕ завершения процесса проектирования. Клиент для такой базы нужен? Если это чисто теоретические изыскания, то ради бога... И объясните мне, пожалуйста, что такое ОДИНАКОВЫЕ справочники. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.04.2004, 10:13 |
|
||
|
|

start [/forum/topic.php?fid=32&msg=32453751&tid=1546538]: |
0ms |
get settings: |
8ms |
get forum list: |
10ms |
check forum access: |
2ms |
check topic access: |
2ms |
track hit: |
161ms |
get topic data: |
9ms |
get forum data: |
2ms |
get page messages: |
48ms |
get tp. blocked users: |
1ms |
| others: | 220ms |
| total: | 463ms |

| 0 / 0 |
