guest_20040621Ну в общем, ничего другого и не ожидалось. Как обычно, никаких внятных аргументов. Соответственно, отсутствует смысл дальнейшего общения.
И что Вы здесь-то побираетесь ? Хотите заработать, предложите свои услуги на форуме "Работа". Уверен, Вы будете пользоваться там большим успехом.
Сергей ВаскецовПроще были бы DDL-ки табличек заголовка, состава и, например, налогов по строке состава, которые ссылаются на состав (если по Вашей логике налоги "захардкодены" прямо в строке состава - не беда, придумайте сами любую табличку, которая бы ссылалась на строку состава и на любой другой совершенно "левый" справочник). А мы бы рассмотрели. А то все такие теоретики, аж жуть.Лучше пообщались бы с топикстартером, если вам есть что сказать. А я вам ничем не обязан, по большому счету, поэтому какие-либо требования или претензии ко мне неуместны. Сергей ВаскецовНа кой, простите, требовать от PK идентификации объекта в реальном мире? И вообще, где это написано?Пожалуйста, не вырывайте фразы из контекста, читайте внимательнее и желательно вдумываясь в общий смысл. Сергей ВаскецовА Вы уверены, что оно всегда мне надо? Как пример в Вашем случае, контроль уникальности №пп я вполне могу оставить до момента утверждения документа, а не выдумывать жесткие констрейнты и затем яростно обходить их при необходимости банального копирования строки. Или просто в ситуации, когда софт установлен у большого количества заказчиков, имеющих различное представление о том, какая же все-таки комбинация полей является уникальной в составе документа.Можно придумать еще много разных эмоциональных ситуаций и что дальше ? Не надо, не делайте, другими словами это уже предлагалось ранее. Сергей ВаскецовКто Вам сказал такую глупость? Есть множество ситуаций (некоторые я привел выше в этом же сообщении), когда никакой естественный ключ на таблице не может существовать как декларативное ограничение.Внимательно перечитал, увидел только надуманные проблемы реализации. Совершенно не обязательно моментальная фиксация изменений в БД в процессе редактирования объекта. Как правило, она выполняется в тразакции по окончании редактирования. А теперь попробуйте ответить себе сами, как пользователь отличает одну позицию от другой ? По суррогатному ключу ? Сергей Васкецов ChAДля зависимых сущностей этот ключ будет составным, именно потому, что они зависимые и, вообще говоря, не могут существовать вне сущности "родителя"Опаньки! То есть, в PK включаются как минимум все обязательные поля в таблице?Хоть убейте, не понимаю логики, которая привела вас к такому выводу.
Сергей Васкецов ChAпоэтому к идентификатору сущности "родителя", добавляется идентификатор этой сущности в рамках родителяВопрос в целесообразности такого включения, а не в том, что если к PK добавить еще и ссылку на родителя, он останется не менее уникальным, чем был PK.Безусловно. Аргументы для включения, как и против, были рассмотрены ранее. Похоже все-таки просто зацепились за фразу и таки не удосужились прочитать топик с начала. Сергей ВаскецовЕсли ее (строки состава без заголовка) нет в реальном мире, то это не значит, что в БД не может быть связи, в которой на заголовок вообще пофигу и нет необходимости учитывать, что он должен быть. Как раз наоборот, раз есть строка состава, то и заголовок есть, так как ссылка на заголовок в составе - обязательное поле.Или я вас не понимаю, или вы сами себе противоречите, но никак не мне.
А строка существует в реальном мире, как только пользователь ее ввел. Может ее еще и нет в БД, но на экране она точно присутствует. И пользователь прекрасно отличает одну похожую строчку от другой. Всего и надо-то понять, каким образом он это делает.
Сергей Васкецов ChAИ эта позиция обязательно чем-то отличается от других ей подобных в этом документе.В простейшем случае, это ее номерПока документ в БД не утвержден, с ним можно делать почти что угодно, и в первом приближении не очевидно, что дял копирования строк состава необходимо уметь на лету править №пп.Забавно, сами же себе ответили на свой же, поставленный выше, вопрос. И, что характерно, он не сильно отличается от моего. Сергей Васкецов ChAВы тыкаете поставщика носом в эту строку и говорите, вот по этой позиции мне недодалиПодозреваю, в такой иллюзорной ситуации (разборки на основании счета-фактуры, а не счета или накладной) используется вовсе не №пп строки состава документа в БД, а то, что на бумажном носителе. У нас №пп хранится в строках состава и им можно управлять, хотя я вполне допускаю, что №пп может формироваться у кого-то только при печати.И что у нас на бумажном носителе ? Я предполагаю, что строки, выведенные в определенном порядке, который однозначно можно восстановить по БД. Хотя для меня лично выглядит несколько абсурдно появление в одной СФ(или накладной) нескольких абсолютно идентичных строк, различающихся, например, только количеством, или только ценой. Если, например, это один и тот же товар, то разумного объяснения такого разбиения я не нахожу. Интересно также, как будут выдавать товар в подобной ситации. Типа, чешем в затылке, потом говорим, это вот из этой кучи, а это из вон той ? Сергей Васкецов ChAНо в любом случае, есть поле, комбинация полей, которые позволяет явно отличить одну строку от другой в данном документе, как внутри БД, так и вне ее, причем сделать взаимооднозначное соотвествиеВо-первых, вообще говоря, неочевидна сама необходимость идентификации строк в БД теми методами, которые Вы предлагаете. Как минимум, потому что, во-вторых, не очевидно, что идентификация "как внутри БД, так и вне ее" должна быть одинаковой; почему бы не иметь различную идентификацию "как внутри БД, так и вне ее"? И уж совсем не понятно, зачем необходимо "взаимооднозначное соотвествие".Вполне возможно, об этом также упоминалось, но вот как вы собираетесь обойтись без соответствия я не понимаю. Данные в БД отражают некую модель реальной жизни, а не находятся в БД сами по себе. Они могут не соотвествовать реальной картине, но тогда, простите, какой в них смысл, кроме задач тестирования производительности СУБД, например ? Сергей ВаскецовДанные в БД можно испоганить множеством способов, изменить ссылку на заголовок в составе - далеко не самый нетривиальный из них.Совершенно верно. Поэтому, если есть возможность избежать их хоть в малейшей мере(
смотрите замечания ModelR по поводу составных ключей), то почему бы этого не сделать ?
