Мастера DELPHI (документация, исходники, скачать)

Основная («Начинающим»)/ Базы / WinAPI / Компоненты / Сети / Media / Игры / Corba и COM / KOL / FreePascal / .Net / Прочее / RSDN.ORG

« предыдущая ветвь | форум | следующая ветвь »

Преемственность данных и суррогатные ключи [IB6.x, dBase, FoxPro]

Страницы: 1 2 >
kaif © (2006-09-20 13:14:00)
Создаю новую систему на основе Firebird на базе старой FoxPro. Данные чрезвычайно ценные и их следует перекачивать в новую систему.
Данные в старой системе не имеют суррогатных ключей - все ключи предметные (коды). Причем юзеры отчасти привыкли к этим кодам.
Я лично сторонник суррогатных ключей, особенно обеспечивающих связи между таблицами.
Но переход на суррогаты вызывает определенные трудности и замедления при перекачке данных из старой системы.

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

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

Petr V. Abramov (2006-09-21 01:11:00) [1]
> Не пожалею ли я, если откажусь от суррогатов конкретнов этом случае?
учитывая
> Я лично сторонник суррогатных ключей, особенно обеспечивающих связи между таблицами.
пожалеешь :)

перегони в FB данные as is, а потом, имея нормальный SQL, реши проблему.
Так же приходилось качать из Pidarox в Oracle. И в FB еще сделай всяческие проверки на целкостность и непротиворечивость.

Johnmen (2006-09-20 20:36:00) [2]
Есть статья на ibase.ru про Суррогатные ключи vs Натуральные. Полезно ознакомиться...

>kaif ©

Я за суррогатные. Везде и сразу...:)

Desdechado (2006-09-20 18:50:00) [3]
Neo Trinitron © (20.09.06 18:37) [17]
1. Естественные имеют тенденцию по заранее неизвестному принципу становиться неуникальными.
2. Если естественные многопольные (а обычно так и есть), то геморрой по поддержке в БД ссылочной целостности сравним только с непрерывной диареей.
3. Суррогатные традиционно числовые, а это намного быстрее в БД, чем непонятно что натуральное.

Val (2006-09-20 18:41:00) [4]
как минимум тем, что не будет соблазна их изменять.

Neo Trinitron (2006-09-20 18:37:00) [5]
> Ничем они не хороши, но намного лучше естественных.

Чем, например?

ANB (2006-09-20 18:31:00) [6]

> Neo Trinitron © (20.09.06 18:18) [15]
> Кто-нибудь может кратко рассказать чем это таким сурогатные
> ключи хороши?

Ничем они не хороши, но намного лучше естественных.

Neo Trinitron (2006-09-20 18:18:00) [7]
Кто-нибудь может кратко рассказать чем это таким сурогатные ключи хороши?

kaif (2006-09-20 18:03:00) [8]
Нужные мне SQL-запросы по старой базе невозможны, так как ADO не может объединять, сравнивая "бинарные" строки с нормальными integer-ами, а в базе полно таких связей. Поэтому приходится разбираться по очереди с каждой таблицей после пробной закачки.

Desdechado © (20.09.06 17:20) [12]
Говорю, как человек, написавший около 20 различных конвертилок разных БД (в которых десятки таблиц).
Суррогатные ключи обязательны, причем сразу

Это сильный довод в пользу суррогатных ключей.
-------------------------------
Всем искреннее спасибо.

ANB (2006-09-20 17:38:00) [9]

> Отсев менее 2-3%

Гы гы. Я пробил себе отсев в 10%. И за поправку данных скриптами мне потом заказчики отдельно коньяк таскали :)

Desdechado (2006-09-20 17:20:00) [10]
Обычно при всяких конвертациях я формирую файлы отсевов, куда складываются записи, не прошедшие по каким-то причинам в БД.
Причины могут быть разные - неверный формат, незаполненность полей, отсутствие необходимых ссылок на справочники и т.п.
Попытки конвертации итерационные, т.е. сконвертили, посмотрели отсев и что осталось. Не понравилось, разбираемся с исходными данными, понравилось - заканчиваем. Отсев менее 2-3% - это нормально, ибо меньше добиться можнотолько огромными рудозатратами, проще вбить по новой, но уже правильно.
Говорю, как человек, написавший около 20 различных конвертилок разных БД (в которых десятки таблиц).
Суррогатные ключи обязательны, причем сразу.

Anatoly Podgoretsky (2006-09-20 16:49:00) [11]
kaif © (20.09.06 16:01) [7]
Я не склоняюсь в данном случае, но если хочешь, то придется на период перевода завести таблицы соответствия.

Val (2006-09-20 16:22:00) [12]
>kaif © (20.09.06 16:08)
нарушенная целостность - это отделный вопрос от данного топика.
чем мешают новые ключи - не очень ясно.
при перекачке добавляете новые поля для пк, генератором создаете новые ид, пишите их кроме самих таблиц еще и в соотв. таблицы-перекодировщики вида OldID|NewID...
решаете проблему ссылочной целостности, создаете внешние ключи...
из-за чего топик-то, если вы все-равно собираетесь менять ключи?

Sergey13 (2006-09-20 16:19:00) [13]
> Например, существуют дубликаты и потерянные ссылки, которые
> я могу выявить лишь после закачки очередной таблицы SQL-
> запросами.

Почему их нельзя выявить в исходной БД теми же запросами?

kaif (2006-09-20 16:08:00) [14]
Вопрос не в старых кодах (которые я в любом случае сохраню в качестве альтернативных ключей) и не в показываниях или непоказываниях суррогатных ключей.
Вопрос в гиморе при перекачках.
Новая система устроена иначе.
Иморт каждой таблицы отдельная процедура делает, так как очень много чего приходится обрабатывать, например, всевозможные числовые данные, закодированные в бинарные строки.
Проблема в том, что только после закачки очередной таблицы я могу вообще разобраться, например, со ссылочной целостностью. Многое нарушено в исходных данных в этом вопросе. Например, существуют дубликаты и потерянные ссылки, которые я могу выявить лишь после закачки очередной таблицы SQL-запросами.
Работа с суррогатами на этом этапе мне бы сильно мешала.
Так что как ни крути вначале я все построю на предметных ключах.
Потом должен буду уже перейти на суррогаты и написать все процедуры импорта заново, так как система должна будет стартовать в какой-то день и именно в этот день нужно будет все разом по новой закачать.

Иначе я бы и не сомневался. Я сегда использую суррогаты.

kaif (2006-09-20 16:01:00) [15]
Я так вижу, что народ склоняется к тому чтобы все же создать суррогатные ключи.

Val (2006-09-20 15:59:00) [16]
>Причем юзеры отчасти привыкли к этим кодам.
А вы не показывайте им суррогатные, если решите перейти.

ANB (2006-09-20 14:19:00) [17]

> kaif © (20.09.06 13:14)

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

xayam (2006-09-20 14:16:00) [18]

> kaif © (20.09.06 13:14)

когда-то этот вопрос называли религиозным, использовать СК или ЕК, я всегда использую СК, а тем более раз переезжаешь на новую бд

alehan (2006-09-20 13:55:00) [19]
У меня была аналогичная ситуация, в фоксе в каждой таблице был первичный ключ типа char(8), сгенерированный, на сколько я понял, случайными данными. Хотя некоторые были и осмысленные.

Перенёс как есть, работало нормально через BDE несколько лет. (Ключ брался из генератора cast(gen_id(gen_name,1) as char(8))

Потом, когда переходил на FIBPlus - сделал ключи целочисленными. Чтоб FIBPlus сам мог генерить sql-запросы на update/insert/delete. Т.ч. лучше немного попариться.

Anatoly Podgoretsky (2006-09-20 13:39:00) [20]
Зачем же ты изначально хочешь помучаться? Оставь как есть.

Страницы: 1 2 >

Наверх

	« предыдущая ветвь \| форум \| следующая ветвь »