|
|
|
Справочники
|
|||
|---|---|---|---|
|
#18+
Здравствуйте. В любой (практический любой) базе есть элементарные справочники. Под элементарными справочниками я подразумеваю Id, Name. Это различные типы, статусы итд итп. Возможен еще синоним записи для привязки логики на интерфейсе, типа отображать только открытые талоны. Хардкорные программисты вместо этого используют айдишники, но не о том речь. Так вот, хочу узнать ваше мнение, как лучше организовать работу с такими справочниками. Вижу несколько вариантов. 1. Каждый справочник - отдельная таблица. Если доступ к базе организован посредствам хранимых процедур, то это минимум по 2 процедуры на каждую таблицу, при этом все процедуры под копирку. 2. Общий справочник, в котором иерархически (id, idParent) расположены записи. Родитель - имя справочника, дочерние - элементы. Доступ к элементам справочника организован посредствам одной хранимой процедуры (не считаю редактирование), которая принимает синоним или Id родителя и возвращает элементцы. Так организован справочник в системе, с которой я работаю сейчас. Преимущество - работа со справочником осуществляется централизованно, недостаток - храним служебную информацию в бд, сообтветственно, при переносе базы с девелоперского сервера на прод надо синхронизировать структуру справочника => лишний геморой. Кроме того, в этом случае плохо работает ограничение целостности. Внешний ключ ссылается на общий справочник, а значит, есть гарантия только того, что в поле попадет значение из общего справочника, но не факт что из нужного. Это можно контроллировать триггером, но тогда еще больше лишнего гемороя, мы по сути берем на себя часть работы СУБД. Пожалуйста, поделитесь своим опытом по данному вопросу. Заранее благодарю. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 29.05.2012, 10:40 |
|
||
|
Справочники
|
|||
|---|---|---|---|
|
#18+
AnaceHПожалуйста, поделитесь своим опытом по данному вопросу. Если новый справочник заводит энд юзер, то таблица одна ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 29.05.2012, 11:22 |
|
||
|
Справочники
|
|||
|---|---|---|---|
|
#18+
AnaceH, Оба ваши варианта абсолютно нормальные и могут присутствовать в любой БД. С единственным уточнением что первый вариант может обслуживаться одной хранимкой (ведь ничто незапрещает нам передать в нее например кроме параметров полей еще и талицу в которой все это делать). Но это уже детали. Кроме того непонятно высказывание насчет того что : Кроме того, в этом случае плохо работает ограничение целостности. Внешний ключ ссылается на общий справочник, а значит, есть гарантия только того, что в поле попадет значение из общего справочника, но не факт что из нужного. Как по мне то все нормально. И собственно что вас интересует из опыта? Как я уже сказал оба варианта жизнеспособны. Первый используется когда нет необходимости строить дерево. Второй - когда есть. И синхронизация вполне нормально идет. Даже с одновременным заведением элементов в разных базах. Уточните вопрос. Желательно с примером. Может у вас просто подход неправильный. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 29.05.2012, 11:43 |
|
||
|
Справочники
|
|||
|---|---|---|---|
|
#18+
AnaceHПод элементарными справочниками я подразумеваю Id, Name. через какое-то время обязательно один из "элементарных" справочников захочет расшириться (например, заиметь хронологичность) - что будете делать? Расширять все? Или выносить в отдельную таблицу с сопутствующими изменениями всего и вся? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 29.05.2012, 13:07 |
|
||
|
Справочники
|
|||
|---|---|---|---|
|
#18+
Вариант один однозначно. У второго варианта не вижу преимуществ (уменьшение числа объектов это не преимущество), зато вижу кучу недостатков. ИМХО это усложнение ради усложнения, типа и так тоже могу (я сам ходил этой дорогой и вернулся) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 29.05.2012, 16:04 |
|
||
|
Справочники
|
|||
|---|---|---|---|
|
#18+
mvbодин из "элементарных" справочников захочет расшириться (например, заиметь хронологичность) - что будете делать? Расширять все? Или выносить в отдельную таблицу с сопутствующими изменениями всего и вся? Хронологические атрибуты по жизни хранятся отдельно от самих сущностей. Зачем ради их появления что-то менять? Posted via ActualForum NNTP Server 1.5 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 29.05.2012, 16:19 |
|
||
|
Справочники
|
|||
|---|---|---|---|
|
#18+
Dimitry SibiryakovХронологические атрибуты по жизни хранятся отдельно от самих сущностей. Зачем ради их появления что-то менять? выкручиваться с отдельными табличками можно, конечно, вопрос в том, что в итоге окажется "дешевле" - иметь одну универсальную табличку с кучей расширений или пусть несколько, но самодостаточных сущностей.. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.05.2012, 06:55 |
|
||
|
Справочники
|
|||
|---|---|---|---|
|
#18+
авторКроме того непонятно высказывание насчет того что : Кроме того, в этом случае плохо работает ограничение целостности. Внешний ключ ссылается на общий справочник, а значит, есть гарантия только того, что в поле попадет значение из общего справочника, но не факт что из нужного. Как по мне то все нормально. Вот тут как раз таки не очень нормально, ибо рано или поздно в таблице Сделки поле Вид сделки окажется значение, например, из справочника с типом Вид свифтовки. ЧТобы этого не произошло, придётся на таблице сделок делать триггер, который будет ходить в таблицу справочников, вытягивать тип и сравнивать с захардкоженным в триггере позволенным типом справочника для этого поля. А если в искомой таблице положим 10 справочных полей, то 10 раз долбить БД запросами на получение типа (хотя их конечно можно закэшировать, но это лишний гемор особенно с учетом обновления справочников пользователями) для одного апдейта или инсерта искомой таблицы как-то стрёмно.... Я сам раньше нарвался на эти грабли и теперь разгребаю - у меня была таблица статусов с полем Тип статусов, соответственно в различных таблицах, где я ссылаюсь на эти статусы приходится проверять в триггерах допустимость типов данных статусов редактируемой таблице.... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.05.2012, 15:56 |
|
||
|
Справочники
|
|||
|---|---|---|---|
|
#18+
Это т вариант очень хорошо использоватть, потому как экономит много сил: 2. Общий справочник, в котором иерархически (id, idParent) расположены записи. НЕ понятно, что это вдруго иерархический. Не должно быть там никакой иерархии. Родитель - имя справочника, дочерние - элементы. Имя справочника (это должен быть отдельный метасправочник) идёт в PK таблицы, там ещё будет ID. ОТкуда иерархия ? сервера на прод надо синхронизировать структуру справочника => лишний геморой. Кроме того, в этом случае плохо работает ограничение целостности. Да, это есть. Надо по идее проверять дополнительно логикой в процедурах или триггерах. Но это можно и не делать, если есть какие-то промежуточные слои логики редактирования, которые не позволяют так сделать. Но лучше конечно добавлять. а дилемма -- ну, когда у тебя этих справочников штут 100 -- вариантов нет. 2-3 -- можно сделать по-простому, в отдельных таблицах. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 31.05.2012, 18:07 |
|
||
|
Справочники
|
|||
|---|---|---|---|
|
#18+
AnaceH, Думаю, что справочников в системе должно быть чуть - единицы измерения, наименования дней недели, еще какие-то совсем общие сведения. Все остальные якобы "справочники" в итоге оказываются вполне обычными сущностями предметной области - обычно с уникальным набором данных и собственным поведением. Так что всегда и без исключений вариант 1. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.06.2012, 08:15 |
|
||
|
Справочники
|
|||
|---|---|---|---|
|
#18+
kolesovТак что всегда и без исключений вариант 1. Зависит от принятой модели. Например такой: сущности в отдельных плоских таблицах, справочники только классифицируют сущности и имеют иерархическую структуру (все в одной таблице). ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.06.2012, 09:39 |
|
||
|
Справочники
|
|||
|---|---|---|---|
|
#18+
AnaceHПожалуйста, поделитесь своим опытом по данному вопросу. Способ 2 кульхацкерский, поэтому, думаю, большинство голосов будет за него. Дело в том, что очень скучно легко и просто работать "как надо", гораздо круче тратить время и силы на изобретение велосипеда и потому чувствовать себя крутым и неслабым. На практике есть пожалуй что один случай, когда второй вариант удобнее: это ситуация, когда справочники определяются пользователем (скажем, всякие произвольные аналитические признаки). Во всех остальных случаях это только дополнительные недостатки и дополнительный геморрой. Этот способ "нереляционный" и поэтому применение его в реляционных операциях печально. Даже просто использовать справочник в запросе - уже менее удобно, а уж добавить в справочник новое поле - задача вообще нерешаемая. В качестве побочного эффекта получим плохую эффективность запросов, поскольку оптимизатор, видя ссылку на таблицу с тысячью записей, сочтёт индекс селективным и жестоко ошибётся. Когда-то давно второй способ можно было обосновать применением убогих инструментов разработки клиента, заставлявших плодить тысячу одинаковых форм для тысячи справочников. Но уже десять лет назад такой аргумент смотрелся "приветом с кладбища". ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.06.2012, 10:46 |
|
||
|
Справочники
|
|||
|---|---|---|---|
|
#18+
On 06/06/2012 09:15 AM, kolesov wrote: > Думаю, что справочников в системе должно быть чуть - единицы измерения, > наименования дней недели, еще какие-то совсем общие сведения. Все остальные > якобы "справочники" в итоге оказываются вполне обычными сущностями предметной > области - обычно с уникальным набором данных и собственным поведением. Так что > всегда и без исключений вариант 1. Так надо ж сначала дать определение справочкика. Справочник -- неизменяемая сущность предметной области. (меняется только с предметной обласью вместе). Posted via ActualForum NNTP Server 1.5 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.06.2012, 11:15 |
|
||
|
Справочники
|
|||
|---|---|---|---|
|
#18+
MasterZiv, справочник = чужой классификатор, с которым вынуждены работать ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.06.2012, 11:47 |
|
||
|
Справочники
|
|||
|---|---|---|---|
|
#18+
AnaceH, есть два варианта :) 1. создавать кучу "справочников" и дать возможность их обобщить 2. создавать 1 "справочник" и дать возможность его разбить 1 и 2 ничем не отличаются ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.06.2012, 11:52 |
|
||
|
Справочники
|
|||
|---|---|---|---|
|
#18+
kolesovAnaceH, Думаю, что справочников в системе должно быть чуть - единицы измерения, наименования дней недели, еще какие-то совсем общие сведения. Все остальные якобы "справочники" в итоге оказываются вполне обычными сущностями предметной области - обычно с уникальным набором данных и собственным поведением. Так что всегда и без исключений вариант 1. Даже в этом случае структуру не всегда можно уложить в шаблон "Id, Name". У единицы измерения может быть сокращенное и полное наименование (Г,грамм), принадлежность к классу (масса), признаки (основная/не основная) и т.п. Обычно в реальных системах имеется сочетание 1 и 2 подходов (чаще 1). ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 25.06.2012, 20:05 |
|
||
|
Справочники
|
|||
|---|---|---|---|
|
#18+
ksv55У единицы измерения может быть сокращенное и полное наименование (Г,грамм), принадлежность к классу (масса), признаки (основная/не основная) и т.п. ОКЕИ тот же ))) Вариант 1 позволяет возложить многое на СУБД, как то упрощение администрирования, репликации. Вариант 2 бывает незаменим, если надо "администрировать само администрирование", и вообще если конечные "клиенты" сами воротят всякие "справочники": этот чел имеет такие-то права на эти атрибуты номенклатуры, а на эти - не имеет. Впрочем обычно НСИ в общем виде не укладывается в одну таблицу, так что и 1 и 2 бывает. И кстати справочник не является синонимом классификатора. Очевидность этого очевидна: над одним справочником той же номенклатуры могут быть несколько (более одного) классификаторов. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.06.2012, 03:48 |
|
||
|
Справочники
|
|||
|---|---|---|---|
|
#18+
Сергей ВаскецовИ кстати справочник не является синонимом классификатора. Похоже ТС имел ввиду именно классификаторы ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.06.2012, 09:47 |
|
||
|
Справочники
|
|||
|---|---|---|---|
|
#18+
AnaceHЗдравствуйте. В любой (практический любой) базе есть элементарные справочники. Под элементарными справочниками я подразумеваю Id, Name. Это различные типы, статусы итд итп. Возможен еще синоним записи для привязки логики на интерфейсе, типа отображать только открытые талоны. Хардкорные программисты вместо этого используют айдишники, но не о том речь. Так вот, хочу узнать ваше мнение, как лучше организовать работу с такими справочниками. Вижу несколько вариантов. 1. Каждый справочник - отдельная таблица. Если доступ к базе организован посредствам хранимых процедур, то это минимум по 2 процедуры на каждую таблицу, при этом все процедуры под копирку. 2. Общий справочник, в котором иерархически (id, idParent) расположены записи. Родитель - имя справочника, дочерние - элементы. Доступ к элементам справочника организован посредствам одной хранимой процедуры (не считаю редактирование), которая принимает синоним или Id родителя и возвращает элементцы. Здравствуйте. Вы не видите еще одного важного варианта. Во-первых, практически любое "поле" в "таблице" (я использую наиболее распространенную терминологию) представляет собой "элементарный справочник" (классификатор). Ведь когда Вы вводите в поле Фамилия данной записи значение Петров, Вы относите человека, которому соответствует эта запись в БД, к классу людей, имеющих фамилию Петров. А когда Вы вводите в поле Дата рождения значение 15.05.1990, Вы относите человека к классу людей, родившихся 15.05.1990. Во-вторых, когда речь идет о "технологических справочниках", управляемых разработчиками (с условно постоянным перечнем элементов), удобнее использовать поле, а не таблицу. То есть, в любом из этих случаев правильным вариантом реализации классификатора или "элементарного справочника" является соответствующий тип поля, а вовсе не таблица:) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.06.2012, 21:47 |
|
||
|
Справочники
|
|||
|---|---|---|---|
|
#18+
kmaw Буквы... Забыли про пикселы, если есть охота пошутить))) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.06.2012, 01:09 |
|
||
|
Справочники
|
|||
|---|---|---|---|
|
#18+
Элементарные справочники, ТС, - стандартные, общие для любых баз данных сущности, управляемые, как правило, централизованно и единообразно. Стандартные единицы измерений, например. А типы, статусы и пр. фигня чаще всего - плоская разновидность категоризации. Классификаторы - правильно построенные - тоже разновидность категоризации, но более сложная, предполагающая дополнительные структуры данных. Никаких общих рекомендаций для реализации всего вышеперечисленного нет. То, что у вас поименовано под п. 2 - типичная ошибка проектирования. Просто запомните, что так делать не следует. Исключения есть, но для вас они не представляют практического интереса. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.06.2012, 01:26 |
|
||
|
|
start [/forum/topic.php?fid=32&fpage=47&tid=1541625]: |
0ms |
get settings: |
10ms |
get forum list: |
16ms |
check forum access: |
4ms |
check topic access: |
4ms |
track hit: |
74ms |
get topic data: |
11ms |
get forum data: |
3ms |
get page messages: |
94ms |
get tp. blocked users: |
2ms |
| others: | 240ms |
| total: | 458ms |
| 0 / 0 |
