Goffmanчто конкретно из этого поста опровергает мои слова? это то же самое, что говорил я, только другими словами
автор.....То есть никакой физической связи со справочником заявок не будет, а вся логика будет перенесена на уровень приложения...Как не будет. А FK на что? :) Ниже же сами процитировали.
...Физическая связь может и присутствовать, другое дело, ты не сможешь средствами СУБД (констрейнтов) контролировать, что в нужную таблицу попали значения именно из нужного справочника...FK ограничивает? Да. Но допускает использование данных других справочников, что не есть хорошо. Формально и фактически тем не менее физическая связь будет. Этот вариант предлагал не я, но тем не менее мои коллеги его используютGoffmanМногие, в том числе и я, такой подход не одобрят, но в конце концов, это ваше делоНичего личного, но честно говоря, мне Ваше мнение (пока оно не будет достаточно аргументированным), мягко говоря, до лампочки, а уж одобрение еще больше.Goffmanя так понимаю, вы пытаетесь примерить ситуацию на собственные разработки. Не спорю что в вашем конкретном случае проблем с изменением схемы данных нет. Я пытался привести проблему в общем виде. А предмета для спора, считаю здесь нет, трудоемкость перепроектирования системы сильно зависит от масштаба системы.В каком моем конкретном случае? Я нигде не приводил описание своих конкретных случаев, а уж тем более взывал к разуму почти в каждом посте при выборе того или иного решения. Это как раз вообщем. А теперь давайте к конкретике - будьте добры, опишите, что в ваших системах содержат ХП, что правка превращается в сущий ад, требующий недюжих сил?

guest_20040621Браво. Появляются автомобили с уникальным цветовым кодированием и уникальным именем цвета каждого вендора - добавляем новый справочник. Появляется необходимость учёта цвета и фактуры - добавляем ещё один справочник. Появляется необходимость использовать цветовые комбинации - добавляем ещё один.Я так понял, у тебя есть серебряная пуля. Поделись пожалуйста, а то народ мучается, головы ломает...

SERG1257Э нет, так дело не пойдет.
Есть традиционный банальный подход - мухи отдельно, котлеты отдельно. Правильно, банально, скучно.
Да конечно отдельно, я поэтому и просил указать, что же там такое лежит, что работать прям нельзя. И этот вопрос никак не связан с общим справочником, поскольку любая другая миграция справочников (слияние справочников например) вызывает потребность в тех же действиях. Так что дело идет дальше :)
SERG1257Вы утверждаете, что если нарушить правила, то можно получить некие преимущества. Причем какие именно преимущеста озвучено не было. Было сказано - мне удобно , чисто субъективный критерий (может удобно потому что привычно). EAV предлагаю убрать за скобки.
В то время, как я могу привести недостатки такого подхода, пусть маловероятные, но объективные.Да и без EAV достаточно. Вот коллега, например, говорил: 15434142 . Там еще есть примеры, если поискать. Никто вас не принуждает делать так, как описано и никто не утверждал, что применение общего справочника - единственно верный метод. Просто такой подход позволяет экономить время и упрощает проектирование, разработку и сопровождение в многих случаях.

SERG1257Infernal V. Raven Вот коллега, например, говорилЯ там же коллеге возражал. И ответов не получил. Потому что на "мне так удобно" - крыть нечем.
Ну давай я отвечу
-- Задолбало иметь десятки таблиц с 2-5 записями в каждой.
--- Чем именно это напрягает?
Меня и других коллег напрягает иметь кучу таблиц, с однотипной структурой и однотипными запросами, но к разным таблицам, и то что эти таблицы нужно обслуживать, вместо того, чтобы реализовать единый стандарт хранения и взаимодействия со схожими данными. Да, это удобно. Поэтому аргумент "удобно" перестает быть субъективным, а становится объективным.

-- Задолбало придумывать им имена.
--- А логические имена придумывать типа не надо.
Придумывать названия надо и более того желательно также подход к именованию стандартизовать.

-- а потом будешь столько-же искать эту чёртову таблицу
--- Пользуйтесь словарем БД
Да можно конечно пользоваться словарем, но комментирование таблиц различается в СУБД. И тем более различается способом и удобство получения этих комментариев. Искать по описанию таблицу в MSSQL, например, не так приятно, а в описании справочника в таблице - удобнее.

-- Здесь же поиск искомого значения в один клик.
--- Создайте вьюху с union all чтобы искать в один клик. Не убедил
Ну это меня вообще убило. Городить вьюху (и поддерживать ее) вместо изначально типизированного решения это конечно да, намного удобнее. Снимаю шляпу - мсье знает толк в извращениях.

SERG1257Приходит к вам крошка сын (типа ТС) и спрашивает: а можно ли стоять под стрелой, не мыть руки перед едой или переходить дорогу в неположенном месте. Что вы ему ответите на законный вопрос: "а я это вчера делал и мне ничего не было. Нафиг тогда эти правила, мне так удобно"Передергиваете. Я бы привел другой пример - есть дорога, которую нужно перейти, при этом пешеходного перехода в ближайшем обозрении нет. Если дорога по 3 ряда в каждую сторону с плотным движением, то тут даже многим альтернативно одаренным понятно, что делать этого не следует. А если это дорога в глухом районе на окраине города, то можно перейти ее оглянувшись по сторонам. Суть аналогии, надеюсь, уловили.
SERG1257разработку ограниченно согласен - не верю, что слепить форму по шаблону занимает много больше времени.
сопровождение - категорически не согласен. Для сопровождения все эти кунштюки - как серпом. Пусть безобразно, но единообразно.По разработке - это как раз унификация. Примеров масса, во многих промышленных системах. По сопровождению, говорили уже, что стараться минимизировать операции DDL - нормальная практика.

guest_20040621Цвет - удачный пример несостоятельности распространённой реализации "всё в одном". Если вы посмотрите чуть дальше, то легко увидите, что и стандартных способов кодирования цвета больше одного. Плюс отраслевые. Плюс вендор-лок. Плюс сочетания. Для обычных задач этого вполне достаточно.И о чем это говорит? На мой взгляд о том, что нужно пойти от задачи и проектировать соответствующим образом в зависимости от нее, а не от сферического коня представленного тобой :)

guest_20040621> о чем это говорит?

О том, что проектированием баз данных занимаются по большей части долбо^бы, не имеющие ни малейшего представления ни о стандартах, ни о правилах проектирования, ни о решаемых задачах. Исключения есть, сложность в том, что и постановкой задач занимаются такие же долбо^бы, - у разработчика должен быть ну очень не тривиальный подход, чтобы и хотеть, и иметь возможность выйти за рамки "работает - не трогай".

> нужно пойти от задачи

Продемонстрируйте ваш навык "пойти от задачи". Задача тривиальнейшая: контекстно-зависимый справочник.Ну уж Д'Артаньяну демонстрировать желания нет, уж извини :)

GoffmanНу и что толку от этой физической связи, если она, цитирую вас, "допускает использование данных других справочников, что не есть хорошо"?Ну я и говорил, что предпочитаю не делать FK, хотя кто-то их делает.
GoffmanВ общем то я выражал свое мнение не о вас, а о вашем подходе к проектированию. Но если вы уж так не терпите критики, зачем тогда приводить свои методы работы в качестве аргумента?Да как же. Как можно понять по-другому Вашу формулировку? По-моему это личная оценка и никак иначе.
Что касается проектирования, то единственным аргументом против использования общего справочника действительно является отсутствие FK на значение справочника. Если это не является критичным (я уже устал повторять, что на каждый справочник нужно смотреть), то я (и другие проектировщики различных систем) готовы этим пожертвовать. Других аргументов пока не поступало.
GoffmanА это, вы разве не на примере своей системы описывали? Если нет - то смею вас уверить, что далеко не у всех все так идеально.Идеальных систем не встречал. В основном я привожу примеры из своей практики, но в первую очередь пытаюсь узнать, что за проблемы в системах коллег и какая задача решается, в частности и вашей, чтобы не давать необдуманных советов.
GoffmanБывает и так, когда на предприятии зоопарк систем, которые разрабатывались в разное время на разных платформах, потом между ними проводилась интеграция. Каким тут поиском пройдешь? В этих условиях ни один ит-шник не сможет на 100% сказать, в каких частях системы используется та или иная таблица. Поэтому любые работы связанные с перепроектированием систем очень неприятны и трудоемки, нужно подстраховываться, какое то время вести параллельный ввод и т.д.
Надеюсь на этот раз понятно объяснил :)Да что вы, правда? :) И что вот так прямо для такой работающей системы возникнет мысль переориентировать справочник->лукап или наоборот? Вот уж не поверю ни разу, поскольку если речь идет о перепроектировании, то проектируется система которая развернута рядом и в нее выполняется миграция. Именно по причине трудоемкости выяснения вопроса "в каких частях системы используется та или иная таблица". Так что теплое с мягким путать не надо.