Dmitri Kuzmenko пишет:
М.Королев wrote:
Ничо не понял.
Почему домен должен отражать смысл, да еще в таком узком смысле? :)
Чем плох DNAME в качестве домена для First, Middle и прочих Name'ов?
Чем плох DID в качестве домена для ID'ов (чеки в домен не включаем) ?
От чего спасает наличие разных системных доменов для одинаковых типов?
Когда LastName перестает быть равен FirstName по типу и формату?
Тупой я сёдня
Хреново вы, батенька, в моделировании упражнялись :-)
Хуже скажу, - я в игре на контрабасе вообще не упражнялся :)
Но это не мешает мне настраивать гитару. Потому что для этого
_достаточно_ слуха, рук и знания приемов настройки.
FirstName <> LastName потому что первое это ИМЯ, а второе - ФАМИЛИЯ.
Первая реакция - дать достойный ответ на столь грубый наезд :)
Но что-то зацепило, и подумал, что, возможно, здесь-то и лежит камень
взаимонепонимания с угОльными краями.
Так вот. Я бы принял (с натяжкой) это в качестве аргумента, если бы
собирался в рантайме анализировать имя домена и выполнять какую-то
обработку данных, зависящую от этого имени. Ну например, автоматически
преобразовывать все поля DNAME в верхний регистр. Или интерпретировать
имя домена как имя класса объекта.
Но я не собираюсь этого делать! И не потому что нельзя или плохо, а
просто потому, что это не входит в _мои_ приемы настройки гитары.
А Имя это не Фамилия. Я думаю, редко какому разработчику в голову придет
написать
update persons
set LAST_NAME = FIRST_NAME
where ...
или
select ...
from A, B
where A.LAST_NAME = B.FIRST_NAME,
разве не так?
И так и не так. Редко какому, потому что задача такая редко возникает. А
если поставить задачу выявить процент китайцев, у которых в полном имени
есть одинаковые слова, то _любой_ разработчик примерно это и напишет.
Вообще, пример с именами неудачный. Т.к. даже если ты считаешь, что имя
и фамилия - объекты разных классов, то все равно у них есть общий
предок. И больше сходства, чем различий в формате, размере и т.д.
И точно так же ID в таблице товаров не равен ID в таблице клиентов.
Потому что еще и может формироваться по разным правилам.
И вообще, извините меня, это ....., писать
Да не надо им общий домен давать, если по разным правилам! НЕ НАДО!
Вопрос опять в общем предке и степени сходства-различия.
А многоточие не понял. Говорю же, туп-с!
create domain DID NOT NULL,
а потом везде этот домен клепать, когда можно было просто написать
столбцам ID INT NOT NULL.
Не верю я, что ты не понимаешь, зачем это может быть нужно.
Я может перегибаю с тоном, но я не могу понять удовольствия
от использования вот этого самого DID.
А холивар так холивар :) Кто не с нами, тот против нас!
И вообще, Дмитрий, я вычеркиваю из твоей характеристики фразу
"величайший гений базостроения". и оставляю просто "великий гений
базостроения". Вот так вот. Великий гений и ни копейки больше :)
Например, при моделировании структуры БД в концептуальной модели
один и тот же атрибут нельзя использовать в качестве идентификатора
более чем одной таблицы. Потому что таблица - сущность. И
идентицифируется каждая по своему, пусть даже им всем десяти
влуплены генераторы типа GEN_N и они отщелкиваются с одинаковым шагом.
Шайтан! Вот он - незамутненный источник знания!
Ты бы так сразу и сказал - "хочу, чтобы схема БД удовлетворяла
требованиям конкретного моделлера". Или UML. Или еще чего-нибудь умного
и запрещающего тебе использовать один домен для ID'ов разных таблиц.
А если серьезно, я согласен с описанным тобой ограничением, если
упомянутый атрибут - это атрибут предметной области (модель-то
концептуальная). Но какое отношение к этому имеет мой суррогатный ID ?
Так что если эта практика повлияла на твое отношение к DID'у, - то это
влияние игры на контрабасе при настройке гитары.
В общем, не надо меня разочаровывать :-) Я понимаю - нормализация
не догма, наличие FK не догма, not null в FK не догма, и так далее.
Но хоть что-то святое должно же остаться? :-)
Хорошо сказал. Присоединяюсь.
p.s. дорвались, понимаешь, до доменов...
Не говори.
И давай не будем дальше холиварить. Неблагодарное это дело. Времени
тратишь вагон, а результата - никакого, потому что переубедить оппонента
не удается.
А если удается, - то это уже не холивар :)
