MaratIskзапомни навсегда - значимое поле никогда не используй в качестве ключа
дискутировать на этот счет можно бесконечно, но лучше просто принять за аксиомуВот и еще один кандидат на отрывание рук и головы.
В качестве первичного ключа всегда надо брать тот который наиболее удобен для кластерного индекса и для создания внешних ключей. Является ли при этом используемое поле естественным или суррогатным это уже вторично.
Хотя лично я за суррогантные ключи убивал бы.


shalx, не удаляй строки вообще. Помечай их "удаленными" и прячь от показа, но физически не удаляй. Тогда у тебя будет возможность откатить назад и показать что вот такая-то проводка была удалена МарьВанной в такой-то день и пусть уже МарьВанна объясняет почему она удалила проводку. А если ты будешь удалять строки физически, то уже ничего потом не сможешь доказать - программа потеряла пару миллионов, значит виноват программист.

MaratIskWhite Owl,

угу, сколько версий id = 2 будет у него в таблице??? ему же нужно восстановить последовательность. а откат и показ марьивановне организуется совсем иначеЯ же сказал: за суррогатные ключи отрывать руки и ноги. Голову оставлять чтобы она страдала.

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

Только если естественный ключ получается очень длинным и на нем еще надо основывать внешние ключи - тогда и только тогда целесообразность суррогатного может подрасти настолько что его можно будет использовать. Но даже тогда - без серьезной обвязки триггерами суррогаты это верный путь к потере целостности данных и вечная головная боль при поиске данных в зависимых таблицах.

PPAВ моей практике естественный ключ всегда получается составной
люди любят чтобы объекты с нового года/месяца нумеровался начиналась с 1 т.е. приходится приклеивать "год"
а с составным PK это гарантированное снижение эффективности:Но ведь естественный ключ у тебя все равно есть. Ты его боишься использовать по причине его длины, но он есть.

PPA - Увеличение объема индексов и дочерних таблиц (представь что FK-полей тысячи)
- Обрабатывать на триггерах ID проще чем составной кей (в Оракле часто нужно прокидывать ID для обхода мутаций на операторном триггере)
- На клиенте master-detail делать проще
- и т.д. и т.п.Все верно. Но проще не значит надежнее.

PPAи про вечную головную боль вообще не понял - можно пример из жизни в чем боль то?
видел много систем и все на синтетике - никаких проблем не наблюдаетсяДа, можно и с синтетическими ключами жить. Если сделать хорошие и правильные триггера для слежения за целостностью...
А примеры из жизни... ой... Может большинство моих примеров слегка устарели, но я свою карьеру начинал на Clipper и FoxPro. В те времена хорошим PK считался номер строки и про триггеры никто ничего не знал... Мне приходилось чинить целостность баз.

А из современных, ну вот есть у нас в работе сейчас одна поделка, которую явно делали поколения архитекторов баз. Программе всего-то девятнадцать лет, а смотря на структуру базы я четко вижу как минимум четыре стиля проектирования. В некоторых таблицах есть по три суррогатных ключа (somthing_id, something_token и key). Ведомые таблицы ссылаются на эти ключи (иногда на два сразу), но эти ссылки как внешние ключи не объявлены, потому что не все они могут быть удовлетворены. По сути таблицы появившиеся в базе за 90-ые годы надо читать на основе key, таблицы созданные в период 2001-2004 надо читать используя *_id, а все что было добавлено в базу после использует *_token (или *_id, угадывай на per-table basis).
В качестве СУБД MS SQL, но в базе нету ни единого триггера. Вся логика вынесена на клиента. Не так давно разработчики наконец-то догадались поднять уровень изоляции транзакций, так хоть коллизий по ключам последние три года не было.


Да, с суррогатными ключами жить можно. Я видел и хорошие системы использующие всяческие абстрактные id для ключей.
Но у суррогатов есть неприятная особенность - со временем они превращаются в естественные :)
У нас есть система учета в которой все завязано на PID. В начале это был типичный суррогатный ключ - просто номер регистрации клиента по порядку. Но сейчас, когда клиент приходит за какой-нибудь справкой его спрашивают: "а какой у вас PID?"


PPAТакже если PK - естественный - возникает большой гемор при его апдейте(и вообще это очень опасно и часто такое запрещают на триггерах)Да.
Кстати обрати внимание с чего начался этот топик.

PPAПредставь что человек ввел документ номер 3 и приделал к нему кучу дочерних документов
а потом оказалось что нужно дать документу номер 2

Ваши действия?Просто так ничего "оказаться" не может. Если в вашей конторе может "оказаться" что надо документ номер 3 превратить в документ номер 2, то у вас обязательно будет какое-то "распоряжение начальника на перенумерацию". Вот это распоряжение значит и надо вводить в базу как отдельный документ привязанный к основному документу.

shalx"суррогатные ключи" для меня как китайский ,Учись.
shalx не прошу "готовый код", А что же ты просишь?
shalxпросто если знаете какaia из баз самая лутшая для локали скажите пожалуйстаSQLite. Лучшая из встраиваемых.

Кстати что это за бухгалтерия такая которой нужна встраиваемая база? Ты уверен что у тебя всегда будет только один клиент?

PPAWhite OwlПросто так ничего "оказаться" не может. Если в вашей конторе может "оказаться" что надо документ номер 3 превратить в документ номер 2, то у вас обязательно будет какое-то "распоряжение начальника на перенумерацию". Вот это распоряжение значит и надо вводить в базу как отдельный документ привязанный к основному документу.

По распоряжению идут корректировки только в закрытом периоде (месяц)
т.к. они уже ушли в SAP ERP и его сторнированние там не пройдет.
а в пределах месяца - "документы" правят без бумажек (человек любит ошибаться)
если на каждую опечатку просить распоряжение - остановим производство :)Значит PK выбран не верно.

Если ты хочешь чтобы существовал "период свободного переименования документа", то значит выноси этот документ в отдельную таблицу, типа "незаконченных документов", и делай в качестве PK время когда документ был создан. И правь остальные поля как угодно. А по закрытию месяца все документы из этой таблицы переносятся в таблицу "архива". А таблица "незаконченных" очищается. В этой схеме можно сделать и плавающее архивирование - месяц документ не изменялся - он считается законченным.
А еще лучше - поговори со своими бухгалтерами, лучше с со старшим поколением. И узнай как они решали вопрос перенумерации документов когда все документы были бумажными. А потом повтори их инструкции, уже в варианте БД.

MaratIskWhite Owl,

ТС не имеет представления про естественные и суррогатные ключи, а ты ему про встраемость движка субд :)
совсем ребенка запутаешьНе запутаю, а запугаю.
Либо спровоцирую на учебу.