softwarerОлег ГапонА если делать первичным ключом ISO-код, то можно предоставить пользователю этот код ввести для новых записей, или это кто то запрещает ?
И ещё сделать флажок "это действительно ISO код или таки левый", чтобы включить его вторым полем и не напороться на введение новой страны MTS. Или не, лучше придумать правило "левые коды обязательно содержат пробел в середине" Честно говоря, не вижу в такой ситуации проблем с трёхбуквенным ключём по сравнению с целочисленным.

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

Олег ГапонА если делать первичным ключом ISO-код, то можно предоставить пользователю этот код ввести для новых записей, или это кто то запрещает ? В принципе можно, но не нужно делать естественные ключи из того, что ими не является.

Коды стран можно, коды валют тоже, а вот если пришла транзакция с кодом валюты МТС, то наверное правильно выяснить, какая эта валюта, и найти для неё ПК.

Собственно, как и в случае суррогатных ключей. Не вижу никакой разницы

Если ключи валюты 1, 2, 3, 4, 5... , а приходит валюта "МТС" или "Вася", то что с ней делать?

Олег ГапонДля существующих записей блокировать изменение ISO-кода (первичного ключа)Да в общем то для любых записей это надо блокировать. Если этот код может меняться, то его, конечно, нельзя делать ПК.

softwareralexeyvgПри использовании суррогатного целого ключа, видимо, запись с левым кодом тоже должна по вашей методике помечаться пробелом где-нибуть?
Да нет. Суррогатному ключу наплевать, "исошная" эта запись или "левая". Просто будет null в code, если исошный код где-то нужен.null в code не будет, ведь он есть у валюты. Разве что намеренно для валюты с известным исошным кодом записать в поле кода нулл.

Или нужно при поступлении денег c кодом МТС создавать для каждой записи новую валюту с null в поле исошного кода? (ведь МТС - не идентификатор валюты, и у каждой записи может быть валюта любая, как существующая, так и виртуальная)

В общем, какая то странная постановка задачи, так не бывает.

Я не призываю выискивать для каждого случая хоть какой-то естественный ключ, сам обычно использую суррогатные, но часто бывают действительно нормальные кандидаты на естественный ключ, такие как штат США или код страны; почему бы их не использовать?
Не верится всё таки, что вот какой-нибуть штат США вдруг поменяет код.

softwareralexeyvgnull в code не будет, ведь он есть у валюты.
Серьёзно? И какой же именно iso-шный код у валюты "МТС"? :)

По сказанному это вроде как виртуальная валюта. То есть, я так крепко подозреваю, что "400 Mts" всегда равно "400 Mts" и почти наверняка имеют стабильный коэффициент пересчёта в одну из "настоящих" валют. Но вот кода ISO у неё нет и вряд ли будет.
miksoftэто обычные рубли с клиентского счета МТС.В данном случае это рубли. И нужно указать валюту операции "рубли"

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

softwareralexeyvgно часто бывают действительно нормальные кандидаты на естественный ключ, такие как штат США или код страны; почему бы их не использовать?
Потому, что этот подход не влечёт сколько-нибудь заметных преимуществ, но "почти всегда работает".Больших не влечёт. Так я и говорил автору - нужно поговорить с коллегами, узнать, почему они настаивают на таком решении, какие преимущества будут конкретно для их системы.

Собственно, "почти всегда работает" и небольшие преимущества - это достаточно для использования такого решения.

Ведь перейти на суррогатные ключи не просто, а очень просто - нужно только добавить поле кода. А вот перейти наоборот довольно трудоёмко.

softwareralexeyvgНе верится всё таки, что вот какой-нибуть штат США вдруг поменяет код.
Например, штат Техас согласно союзному договору имеет право разделиться на пять независимых штатов в составе США. Какой из них сохранит код, если сохранит?Какой-то сохранит, остальные нет.

Какая разница в данном случае с суррогатными ключами?

При этом, заметьте, эта проблема при разделении штата Техас будет обязательно решена вне вашей системы.

Потому что код 'TX' - это естественный ключ, и он используется именно как идентификатор штата везде, например, в документах, правах, на письмах и т.д.

Поэтому при разделении будут обязательно установлены правила, которым собственно и будет следовать система в том числе.

softwareralexeyvgВ данном случае это рубли. И нужно указать валюту операции "рубли"
Вы хотите сказать, что в другом случае под словами "400 Mts" будут подразумеваться тугрики? В принципе может быть для клиентов с валютными тарифами, если такие есть. Но неизвестно.Я хочу сказать, что т.к. Mts это не код валюты, то для каждой транзакции потенциально подразумевается своя валюта, неизвестная. В первой строке с кодом Mts имеются в виду тугрики, во второй ангилйские фунты и т.д.

Т.е. в транзакциях для всех кодов валют, которых нет, можно спокойно заменять этот код на *** - результат будет такой-же. Если вы действительно не знаете, какая это валюта на самом деле.

Но это абсурдый путь, так никто не будет делать.

В реальности обязательно выяснят (позвонят, напишут, спросят и т.д.) у поставщика данных (откуда пришли транзакции) и узнают, что этот поставщик под кодом Mts имел в виду российские рубли.
И сопоставят ему валюту RUB. Или валюту 12345, если вы используете суррогатный ключ - алгоритм совершенно одинаковый.

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

Не знаю, зачем такая валюта, "тысячи зайчиков"...

У беллорусии есть 2 валюты - BYB и BYR, зайчики и рубли. Зачем заводить ещё 10 валют - зайчик, 10 зайчиков, 100 зайчиков...... - непонятно.

Тот же вариант (приводили выше) ситуации с RUR и RUB. Ведь тоже нету тут никакой проблемы - это просто разные валюты, их нужно по разному учитывать и считать.

softwareralexeyvgСобственно, "почти всегда работает" и небольшие преимущества - это достаточно для использования такого решения.
"Почти всегда работает" - это достаточное основание для того, чтобы никогда не использовать решение вне зависимости от преимуществ. Потому что допустимые решения должны работать "всегда".Критерий правильности решения - это не его идеальность и применимость к любым задачам и бизнес-процессам, которые не планируется решать, но которые в принципе могут решаться.

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

softwareralexeyvgВедь перейти на суррогатные ключи не просто, а очень просто - нужно только добавить поле кода. А вот перейти наоборот довольно трудоёмко.
Любопытное замечание. Давайте тогда в свете оного Вы объясните, нафига заранее закладывать эту "довольно трудоёмко" в проект, строя его на естественных ключах.Нет, как раз "довольно трудоёмко" - это на суррогатных ключах. Я же говорю - для перехода на суррогатные ключи нужно просто добавить поле в таблицу.

А вот обратно - "довольно трудоёмко" - нужно менять кучу связанных данных.

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

softwarerНу что ж, давайте посмотрим разницу на простом примере. Допустим, мы делаем ИС "Губернаторы американских штатов", простейшая информация - кто когда где рулил. Справочник "люди", справочник "штаты", развязка многие ко многим между ними.

Давайте теперь у нас с 09.05.2011 штат Техас разделится на Хьюстон (HS), Остин (AU) и Глухомань (TX). Как это изменение будет сделано при использовании суррогатных ключей:

1) Губернатору Техаса проставим срок завершения полномочий 08.05.2011
2) Записи "Техас" проставим "дата окончания = 09.05.2011"
3) Введём записи HS, AU и TX
4) Дождёмся выборов в новых штатах и введём их губернаторов

Как это будет сделано при использовании естественного ключа - кода штата? Желательно так, чтобы Джон Кеннеди не оказался убитым на территории штата Глухомань?

alexeyvgПри этом, заметьте, эта проблема при разделении штата Техас будет обязательно решена вне вашей системы.
Да наплевать мне на "вне системы", мне важно, чтобы она была просто и корректно решена внутри системы.

Понимаете, "вне системы" - это здесь ключевой момент; тем и хороши естественные ключи, что проблему будет решать кто-то другой :-)

Т.е. с 09.05.2011 штат Техас разделится на Хьюстон (HS), Остин (AU) и Глухомань (GU).
Потому что TX - это ПК штата Техас, которого больше не будет, и этим кодом не будут отмечать новую административную единицу.

Просто потому, что получая данные из других систем, вы будете получать код штата, и только по этому коду будете приписывать данные к штату, у вас просто не будет других вариантов.
Хоть обзаводитесь кучей записей с разными суррогатными ключами и одинаковым кодом - вы не поймёте, к какой записи относится пришедшая транзакция.

softwareralexeyvgКакой-то сохранит, остальные нет.
Обозначим эту фразу как (1)

alexeyvgТ.е. с 09.05.2011 штат Техас разделится на Хьюстон (HS), Остин (AU) и Глухомань (GU).
Не-не-не, Дэвид Блейн, не-не-не (ц). Не надо подтасовок, давайте Вы покажете простое решение простой задачи в соответствии с Вашей же фразой (1) о том, что один из новых штатов сохранит код старого.1. Если будет как во фразе 1, то будет разъяснение считать Глухомань правоприёмницей Техаса, и да, Джон Кеннеди убит в Глухомани.

2. Если нужно различать, то, как я говорил, сделать ключ суррогатным - это просто добавить поле. Никаких данных при этом обновлять не надо, никакого кода править не надо (ну, почти не надо).

3. Давайте всё таки исходить из здравого смысла. Вы же не делаете поля с ценой текстовыми размером до 2-х гигабайт?

А то придёт начальник, скажет - цену будем теперь записывать стихами в виде намёков, а вы, О Боже!авторсо слезами на глазах объясняете начальству "Они сволочи, их надо мочить в сортирах, они не должны были так поступать, потому что это решительно противоречит логике, заложенной в нашу программу на ценах в DECIMAL".

softwareralexeyvgНе знаю, зачем такая валюта, "тысячи зайчиков"...
При адаптации российской системы в Белоруссии для финансовых расчётов в "единицах зайчиков" не хватало разрядной сетки, начинались переполнения и потери точности. Стоимость проекта не стимулировала к глобальному учёту столь уникальной ситуации как валюта в тысячные доли копеек (кажется на тот момент), поэтому решили считать в "тысячах зайчиков".Ну, хорошо, что ошибка проектирования компенсировалась другой ошибкой проектирования :-)

Надо-же, курс валют выражать в десятичной дроби :-)