ReSQL.ru
     
powered by simpleCommunicator - 2.0.60     © 2026 Programmizd 02
Мобильная версия    Контакт    Правила    FAQ    Помощь
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Доб. в избранное | Игнор. тему | Прикреп. тему | Пометить прочит. / непрочит. | Фильтр
Форумы / Проектирование БД [игнор отключен] [закрыт для гостей] / БД справочников предприятия
18 сообщений из 18, страница 1 из 1
БД справочников предприятия
    #32759238
tRaQ
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
tRaQ
Участник
Интересует ваше мнение по вопросам
0. На предприятии работают много разных программных задач, которые пользуют некие справочники. Справочники бывают "внешние", изменения в которых происходят вне предприятия, и "внутренние". Некоторые внутренние справочники некторых задач провязаны с "внешними" справочниками.
Хочется навести порядок, спроектировав общедоступную для всех задач базу справочников, исключив дублирование и по возможности кол-во "внутренних" справочников.

1. Что такое "справочник"? Ведь с точки зрения разных бизнес-задач одни и те же сущности могут выступать в разных ролях. Поясню - например, есть сущность "договор", имеющий "номер". Для одной задачи таблица договоров есть справочник с ключом "номер", а для других это не так. Как ее интегрировать в единый архив справочников (см. п.0)?
...
Рейтинг: 0 / 0
28.10.2004, 14:11
| Ответить | Цитировать | Написать  
БД справочников предприятия
    #32759315
Станислав C.
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Станислав C.
Участник
tRaQИнтересует ваше мнение по вопросам
0. На предприятии работают много разных программных задач, которые пользуют некие справочники. Справочники бывают "внешние", изменения в которых происходят вне предприятия, и "внутренние". Некоторые внутренние справочники некторых задач провязаны с "внешними" справочниками.
Хочется навести порядок, спроектировав общедоступную для всех задач базу справочников, исключив дублирование и по возможности кол-во "внутренних" справочников.
Идея хорошая. Но только осуществимая ли? Надо будет перенастраивать (и может быть даже переписывать) приложения. А как тренировка для мозгов - даже очень!
tRaQ
1. Что такое "справочник"? Ведь с точки зрения разных бизнес-задач одни и те же сущности могут выступать в разных ролях. Поясню - например, есть сущность "договор", имеющий "номер". Для одной задачи таблица договоров есть справочник с ключом "номер", а для других это не так. Как ее интегрировать в единый архив справочников (см. п.0)?
Ну что же, начнем научные дебаты.
Для начала определимся что будем понимать под понятием "справочник".
Я, например, под этим понимаю сущность, имеющую независимое существование . То есть, ту сущность на ER-диаграмме, от которой связи только "отходят". Например, если рассматривать биологическое понятие "дерево", то можно увидеть, что существует связь "дерево"<-"тип дерева" (например,"береза"-"лиственное"). Таким образом, "дерево" не будет являться справочником, а "тип дерева" - будет.

Теперь разберемся с понятием "договор". Существует много видов договоров: договор аренды, агентский договор, договор займа и т.д. Таким образом, сразу же возникает связь "договор"<-"вид договора" и получается, что "договор" не является справочником... С какой стороны на него не смотри...

Ваша очередь обосновывать свою позицию!
...
Рейтинг: 0 / 0
28.10.2004, 14:38
| Ответить | Цитировать | Написать  
БД справочников предприятия
    #32759342
guest_20040621
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
guest_20040621
Гость
> Справочники бывают "внешние", изменения в которых происходят вне
> предприятия, и "внутренние". Некоторые внутренние справочники некторых задач
> провязаны с "внешними" справочниками.

Не могли бы Вы проиллюстрировать различия более доступно? Не очень понимаю, кто "извне" может менять данные (или структуру)?

> Что такое "справочник"?

Относительно редко изменяемые данные, используемые для стандартизации описания сущностей? Т. е., таблицу договоров я бы к справочникам не относил.
...
Рейтинг: 0 / 0
28.10.2004, 14:45
| Ответить | Цитировать | Написать  
БД справочников предприятия
    #32759406
Shultze
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Shultze
Участник
Использую такую структуру справочников:
Код: plaintext
1.
2.
3.
4.
SPR_NAMES - Названия справочников
SPR_ELEMENTS - элементы  8 : 1  связанные с SPR_NAMES, и сами с собой  - образуют дерево
SPR_DEFS - описание дполнительных полей справочника,  8 : 1  с SPR_NAMES, т.е. разные справочники могут иметь разную структуру дополнительной информации
SPR_VALS - значения дополнительных полей справочников  8 : 1  c SPR_DEFS и SPR_ELEMENTS
Получается достаточно удобно, структура расширяема - что бы добавить справочник нужно его просто описать, то же и к дополнительным полям в справочнике, наприме нужно к номенклатуре "Документы" добавить "Срок архивного хранения" описываем в SPR_DEFS числовое поле, и интерпретируем его в коде соответственно.
...
Рейтинг: 0 / 0
28.10.2004, 15:04
| Ответить | Цитировать | Написать  
БД справочников предприятия
    #32759467
Grey_
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Grey_
Гость
ShultzeИспользую такую структуру справочников:
Код: plaintext
1.
2.
3.
4.
SPR_NAMES - Названия справочников
SPR_ELEMENTS - элементы  8 : 1  связанные с SPR_NAMES, и сами с собой  - образуют дерево
SPR_DEFS - описание дполнительных полей справочника,  8 : 1  с SPR_NAMES, т.е. разные справочники могут иметь разную структуру дополнительной информации
SPR_VALS - значения дополнительных полей справочников  8 : 1  c SPR_DEFS и SPR_ELEMENTS
Получается достаточно удобно, структура расширяема - что бы добавить справочник нужно его просто описать, то же и к дополнительным полям в справочнике, наприме нужно к номенклатуре "Документы" добавить "Срок архивного хранения" описываем в SPR_DEFS числовое поле, и интерпретируем его в коде соответственно.

а если параметры в справочниках имеют разные типы данных?
...
Рейтинг: 0 / 0
28.10.2004, 15:21
| Ответить | Цитировать | Написать  
БД справочников предприятия
    #32759476
guest_20040621
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
guest_20040621
Гость
Member Shultze, в рамках предложенного Вами решения опишите, пожалуйста, как будет выглядеть:

1. административно-территориальный справочник;
2. справочник единиц измерений (с соответствием систем счисления, множителей и пр.);
3. справочник для любых диапазонных величин.

Справитесь - будут еще вопросы.
...
Рейтинг: 0 / 0
28.10.2004, 15:24
| Ответить | Цитировать | Написать  
БД справочников предприятия
    #32759488
Shultze
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Shultze
Участник
Grey_а если параметры в справочниках имеют разные типы данных?

А параметры по любому имеют разные типы данных, который (тип) мы указываем в SPR_DEFS (там же и визуальное представление, например строка редактирования, редактор даты, редактор денег, комбобокс и проч.) сами данные в таблице SPR_VALS могут хранится в поле типа sql_variant, в разных полях (для каждого типа, базовых не много), в одном бинарной (или текстовом) поле и конвертироваться в нужный тип при обработке
...
Рейтинг: 0 / 0
28.10.2004, 15:27
| Ответить | Цитировать | Написать  
БД справочников предприятия
    #32759522
tRaQ
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
tRaQ
Участник
Станислав C.Я, например, под этим понимаю сущность, имеющую независимое существование. То есть, ту сущность на ER-диаграмме, от которой связи только "отходят". Например, если рассматривать биологическое понятие "дерево", то можно увидеть, что существует связь "дерево"<-"тип дерева" (например,"береза"-"лиственное"). Таким образом, "дерево" не будет являться справочником, а "тип дерева" - будет.
С этим пожалуй можно согласится. Единственное, что делать, если вдруг такой "справочник" вдруг становится "несправочником": ДЕРЕВО - ТИП ДЕРЕВА - КЛАСС ТИПА ДЕРЕВА. Переносить из разряда справочников? Я конечно понимаю что структуру БД надо проектировать вначале, но киньте в меня камнем-примером, когда это было выполнено доконца :)

Все волнуются по поводу того что придется переписывать приложения. Я ж не сказал что они уже написаны - просто я предполагаю что начнут скоро стихийно писаться и в случае отстутвия единого хранилища плодить свои справочники :)
...
Рейтинг: 0 / 0
28.10.2004, 15:34
| Ответить | Цитировать | Написать  
БД справочников предприятия
    #32759543
Shultze
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Shultze
Участник
guest_20040621
1. административно-территориальный справочник;
Решение не претендует на универсальность :)) для некоторых вещей лучше (оптимальней) завсти набор таблиц, хотя в справочнике моей формы описать доп. инфо, которое требуется для постороения административно-территориального справочника , как то - типы геонимов, улиц, наименования субъектов и проч.

guest_20040621
2. справочник единиц измерений (с соответствием систем счисления, множителей и пр.);
Элементарно - линейный справочник для каждой системы измерения (наверное Вы это имели в виду, ибо перехот от десятичной к Египетской 60-ричной системы счисления не имеет смысла при измерениях), в доп.полях описываем значение элемента выбранной системы приведенное к метрической в базовых единицах, например для фута - 0,33 метра, для морской мили 1886 м. , для веса 1 унция - 12 грамм... множителя можно указывать два от базовой единицы, если таковая выбрана, и от метрической единицы. Пересчет из одной системы в другую очевиден и не вызовет затруднений.

guest_20040621
3. справочник для любых диапазонных величин.
Не вижу никаких проблем, в SPR_ELEMENTS хранится названия диапазонов, в SPR_DEFS тип и описание нижнего и верхнего (промежуточного, да хоть какого) диапазона, в SPR_VALS - значения для описанных диапазонов


guest_20040621
Справитесь - будут еще вопросы.
Пожалуйста


Вопросы, предложения?
...
Рейтинг: 0 / 0
28.10.2004, 15:39
| Ответить | Цитировать | Написать  
БД справочников предприятия
    #32759555
Grey_
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Grey_
Гость
Shultze

А параметры по любому имеют разные типы данных, который (тип) мы указываем в SPR_DEFS (там же и визуальное представление, например строка редактирования, редактор даты, редактор денег, комбобокс и проч.) сами данные в таблице SPR_VALS могут хранится в поле типа sql_variant, в разных полях (для каждого типа, базовых не много), в одном бинарной (или текстовом) поле и конвертироваться в нужный тип при обработке

с использовани типа sql_variant есть ограничения
...
Рейтинг: 0 / 0
28.10.2004, 15:43
| Ответить | Цитировать | Написать  
БД справочников предприятия
    #32759572
Shultze
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Shultze
Участник
Grey_с использовани типа sql_variant есть ограничения

Есть, но я видать их удачно обходил, пока препятствием не становились.


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

Не надо ничего переносить - древовидны справочник то же справочник, предложенная мной структура их прекрасно поддерживает. В справочник надо относить данные (субъективно, конечно) с которыми не работает конечный пользователь в процессе рутинных операций. Т.е. если ваша программа предназначена для документооборота, пользователь работает с документами, договорами, письмами , но не работает с видами, классами, номенклатурой этих документов, хотя при желании может внести корректировки в справочник, т.е. расширить имеющуюся номенклатуру, или удалить ненужное.
ИМХО связи тут не причем, нужно смотреть от функционала системы
...
Рейтинг: 0 / 0
28.10.2004, 15:49
| Ответить | Цитировать | Написать  
БД справочников предприятия
    #32759617
guest_20040621
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
guest_20040621
Гость
> Решение не претендует на универсальность :)) для некоторых вещей лучше
> (оптимальней) завсти набор таблиц,

Спасибо, это я и хотел услышать. ;)

> Элементарно - линейный справочник для каждой системы измерения

Зачем, позвольте спросить?

> (наверное Вы это имели в виду, ибо перехот от десятичной к Египетской
> 60-ричной системы счисления не имеет смысла при измерениях),

Нет. Но мне понадобится и двоичная, и десятичная.

> приведенное к метрической в базовых единицах, например для фута - 0,33 метра,
> для морской мили 1886 м. , для веса 1 унция - 12 грамм...

Да я пока и не заикался о не-метрических системах. ;) ОК, если Вы настаиваете. ;) Так вот, выбор типа системы счисления (метрическая/не-метрическая) в некоторых случаях связан с гео-сущностями (страной). Тоже как-то слабовато отображается на предложенную Вами структуру. ;)

> Не вижу никаких проблем, в SPR_ELEMENTS хранится названия диапазонов, в
> SPR_DEFS тип и описание нижнего и верхнего (промежуточного, да хоть какого)
> диапазона, в SPR_VALS - значения для описанных диапазонов

Хм... да нет, конечно. Диапазоны могут быть связаны с единицами измерений и иметь собственные характеристики (шаг, например). А для зависимостей в Вашей схеме места нет.

Для чего, собственно, вышенаписанное: предложенное Вами решение безусловно будет работать. В некоторых случаях. Расширить его применение можно добавление типов зависимостей и собственно описанием зависимостей.

Если честно, мне такие решения не очень нравятся и я стараюсь их не использовать.
...
Рейтинг: 0 / 0
28.10.2004, 16:03
| Ответить | Цитировать | Написать  
БД справочников предприятия
    #32759736
Shultze
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Shultze
Участник
guest_20040621> Решение не претендует на универсальность :)) для некоторых вещей лучше
> (оптимальней) завсти набор таблиц,

Спасибо, это я и хотел услышать. ;)

А универсальных решений и нет. Вот, например, есть универсальная птица утка - хреново летает, хреново плавает, хреново бегает. Решения должны быть оптимальными
guest_20040621
> Элементарно - линейный справочник для каждой системы измерения

Зачем, позвольте спросить?

Затем, что любая система измерений есть линейный список - т.е. для длин есть список, для мер весов есть список и т.д.
guest_20040621

Нет. Но мне понадобится и двоичная, и десятичная.

Тут нужно пояснение, в двоичной и десятичной системе значения различаются? Что мешает их персчитывать?

guest_20040621
Да я пока и не заикался о не-метрических системах. ;) ОК, если Вы настаиваете. ;) Так вот, выбор типа системы счисления (метрическая/не-метрическая) в некоторых случаях связан с гео-сущностями (страной). Тоже как-то слабовато отображается на предложенную Вами структуру. ;)

Да, в этой схеме, справочники не могут пересекаться и быть взаимозависимые вне иерархии своего дерева. См. ответ на первый пункт.
Проект где 135 таблиц вида ID,NAME,VALUE1,VALUE2 или ID,NAME,PARENT_ID, они сильно упрощают сводя к 4 таблицам. при этом никто не ограничивает для адресов завести собственный классификатор, для хитрой метрической системы то же самое, и использовать тот или иной подход дело разработчика.
...
Рейтинг: 0 / 0
28.10.2004, 16:43
| Ответить | Цитировать | Написать  
БД справочников предприятия
    #32759877
guest_20040621
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
guest_20040621
Гость
> Затем, что любая система измерений есть линейный список - т.е. для длин есть
> список, для мер весов есть список и т.д.

А что, длина в футах имеет принципиальное отличие от длины в метрах? ;)

> Тут нужно пояснение, в двоичной и десятичной системе значения различаются?

В смысле "различаются"? У них правила отображения разные.

> Что мешает их персчитывать?

Ничто не мешает. Только опять же правила разные. Множитель кило- не эквивалентен множителю киби-, это не очевидно?

> Проект где 135 таблиц вида ID,NAME,VALUE1,VALUE2 или ID,NAME,PARENT_ID, они
> сильно упрощают сводя к 4 таблицам.

Возможно. Только я бы добавил к Вашей схеме еще десяток таблиц, - в таком виде ее еще можно было бы использовать. ;) "Просто" - не всегда синоним "оптимально".

> Да, в этой схеме, справочники не могут пересекаться и быть взаимозависимые
> вне иерархии своего дерева.

Да, это я и имел в виду.
...
Рейтинг: 0 / 0
28.10.2004, 17:29
| Ответить | Цитировать | Написать  
БД справочников предприятия
    #32759932
Shultze
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Shultze
Участник
guest_20040621
А что, длина в футах имеет принципиальное отличие от длины в метрах? ;)

А что, 12 футов уже = 12 метрам? Не суть важно...
Храните список единиц измерений и множитель, вот именно для таких случаев я и предлагал свое решение - что бы огород не городить, а в доп. параметры сохранить множитель, который будет применяться к значению при вычислении данных. А Вы пытаетесь усложнить очевидное и выковырять сложности там где их нет.

guest_20040621
> Тут нужно пояснение, в двоичной и десятичной системе значения различаются?

В смысле "различаются"? У них правила отображения разные.


Не вижу сложностей формализовать задачу и привести ее к моей схеме - храните правило отображения


guest_20040621
Ничто не мешает. Только опять же правила разные. Множитель кило- не эквивалентен множителю киби-, это не очевидно?


Очевидно, еще и то, что множитель задается числовым коэффициентом для элемента, а не приставкой. Пересчет идет по коэффициенту.
guest_20040621
Возможно. Только я бы добавил к Вашей схеме еще десяток таблиц, - в таком виде ее еще можно было бы использовать. ;) "Просто" - не всегда синоним "оптимально".


Не надо ничего туда добавлять, схема самодостаточна и самоописываемая, лучшее враг хорошего. Хотя и интересно, что бы Вы еще туда добавили.

guest_20040621
> Да, в этой схеме, справочники не могут пересекаться и быть взаимозависимые
> вне иерархии своего дерева.

Да, это я и имел в виду.
[/quot]
Дополнительное значение может иметь тип "справочник" и ссылаться на один из справочников из другой иерархии. В SPR_VALS сохраняются ID этих элементов. Т.е. для элемента номенклатуры документов мы можем указать доп.поле "срок хранения" и выбирать срок хранения из справочника сроков "1 Год; 3 Года; 5 Лет; и т.д."
...
Рейтинг: 0 / 0
28.10.2004, 17:47
| Ответить | Цитировать | Написать  
БД справочников предприятия
    #32759982
guest_20040621
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
guest_20040621
Гость
> Не вижу сложностей формализовать задачу и привести ее к моей схеме - храните
> правило отображения

Хех, ну тогда, видимо, нужно описывать и правила отображения для псевдочисловых величин (я дроби имею в виду)? ;) Здесь не получится хранить число. По-видимому, хотелось бы хранить целую часть, числитель и знаменатель дроби отдельно? ;)) (Заметьте, я еще ни слова не сказал о константах). ;)

> Очевидно, еще и то, что множитель задается числовым коэффициентом для
> элемента, а не приставкой. Пересчет идет по коэффициенту.

Не поспоришь. ;) Фишка в том, что применение кратных величин регламентировано. Т. е., в пределах Си Вы не можете использовать произвольные множители. Ы? ;))

> Дополнительное значение может иметь тип "справочник" и ссылаться на один из
> справочников из другой иерархии.

Не думаю, что в общем случае Вы получите приемлемой решение. Необходимо описать еще и тип связи.
...
Рейтинг: 0 / 0
28.10.2004, 18:14
| Ответить | Цитировать | Написать  
БД справочников предприятия
    #32760180
Фотография PL99
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
PL99
Участник
На мой взгляд, создавать метаструктуру для хранения универсальных данных имеет смысл только в том случае, когда с ними не происходит никаких действий, кроме элементарных "создать", "редактировать", "удалить". Как только возникает потребность в реальной обработке, необходимо писать специальный код в приложении, либо расширять метаданные (и усложнять код по их интерпретации).
Относительно иерархических справочников - стремление создать структуру хранения с произвольным уровнем вложенности, IMHO, показатель недостаточно глубокого обследования предметной области на предмет общепринятых классификаций (за некоторым исключением, например, справочник географических пунктов или машиностроительных спецификаций).
...
Рейтинг: 0 / 0
28.10.2004, 20:59
| Ответить | Цитировать | Написать  
БД справочников предприятия
    #32760232
guest_20040621
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
guest_20040621
Гость
> Относительно иерархических справочников - стремление создать структуру
> хранения с произвольным уровнем вложенности, IMHO, показатель недостаточно
> глубокого обследования предметной области на предмет общепринятых
> классификаций

Хм... если можно, поподробнее, что именно Вы считаете "общепринятыми классификациями". Можно с примером.
...
Рейтинг: 0 / 0
28.10.2004, 22:39
| Ответить | Цитировать | Написать  
18 сообщений из 18, страница 1 из 1
Форумы / Проектирование БД [игнор отключен] [закрыт для гостей] / БД справочников предприятия
Найденые пользователи ...
Разблокировать пользователей ...
Читали тему (0):
Читали форум (0):
Пользователи онлайн (0):
x
x
Закрыть


Просмотр
0 / 0
Close
Debug Console [Select Text]