Ключевые поля таблиц, что лучше?

Dr_Grizzly · 12 апр 2007, 06:50

Всем привет! Посоветуйте плииз, пишу базы, сама база в mdb, использую Adoquery для подключения, в самой базе никаких настроек связи и т.д. не делаю, использую только как массив для хранения данных и удобного обращения к полям. А вот все связи я прослеживаю уже в самой программе.
А теперь суть вопроса, какой тип полей лучше использовать для связи данных? Числовой, или по факту? Вот пример числового

key=счетчик
name=текстовый

Таблица 1
key name
1 а
2 б
3 в

Таблица 2
key таб1.key name
1 2 й
2 3 ц
3 1 у

Или по факту, c условием что поле уникально
Таблица 1
key name
1 a
2 б
3 в

Таблица 2
key таб1.name name
1 а й
2 в г
3 б е

Какой из вариантов все лучше? Если все таки первый, то поле счетчик скольки разрядный? До какого предела он может считать?

Игорь Акопян · 12 апр 2007, 10:34

&quot писал(а):До какого предела он может считать?

столько не живут

Используйте вариант 1 - он грамотнее. Опять же, если настроить связи в БД по этому полю, то она построит по нему индекс для ускорения поиска значения, а числовой индекс многократно быстрее строкового

Dr_Grizzly · 12 апр 2007, 18:41

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

Absurd · 13 апр 2007, 14:06

Dr_Grizzly писал(а):Всем привет! Посоветуйте плииз, пишу базы, сама база в mdb, использую Adoquery для подключения, в самой базе никаких настроек связи и т.д. не делаю, использую только как массив для хранения данных и удобного обращения к полям. А вот все связи я прослеживаю уже в самой программе.

В любой базе данных без foreign key constraints существуют несвязанные данные - Т.Кайт

Игорь Акопян · 16 апр 2007, 14:24

&quot писал(а):потом эти ключи есть возможность менять у записей каким-нибудь способом, не удаляя запись

Зачем? Идентификатор записи должен быть уникален, однажды выданный никому больше не присваивается. Во многих системах ничего толком и не удаляется... Просто помечается на удаление

Dr_Grizzly · 22 апр 2007, 08:14

А представьте какого размера будет эта база где будут только помеченные на удаление объекты???

Игорь Акопян · 23 апр 2007, 11:34

во-первых зависит от базы. во-вторых я говорил о том случае, когда ТЗ запрещает удалять объекты, либо требуется вести логи (что ещё больше раздует базу

)
Пользователь - существо не разумное, он может поудалять такое, что потом разработчика просто распнут

Возвращаясь к теме. Никто не запрещает удалять данные, просто нет никаких проблем с тем, что Id записей будут не последоватьены. Главное - уникальны

Absurd · 23 апр 2007, 13:01

Dr_Grizzly писал(а):А представьте какого размера будет эта база где будут только помеченные на удаление объекты???

Зато можно будет раз в полгода объезжать все старые работы, чистить базы и получать за это денюжку.

Naeel Maqsudov · 30 апр 2007, 02:29

&quot писал(а):в самой базе никаких настроек связи и т.д. не делаю, использую только как массив для хранения данных и удобного обращения к полям. А вот все связи я прослеживаю уже в самой программе.

Напрасно. Зачем изобретать велосипед? Вы тут затрагиваете вопрос каскадных обновлений значения ключа в связанных таблицах. Неужели Вы хотите это сами написать? Если эта тема интересна, мы можем пойти на доску по SQL и обсудить вопросы проектирования СУБД.

Теперь по ключам.
1) Естественный первичный ключ. Если во вводимых данных есть уникальный идентификатор (например в табл Сертификаты номер, который перепечатывается с гознаковского бланка), и если он числовой, то следует использовать его. Нечисловые (напр, текстовые) ПК допустимы в маленьких базах (Если строк, скажем, до нескольких тысяч, то разница в производительности не будет обнаруживаться)
Бывает, что уникальной бывает комбинация значений (например, серия+номер документа). Такой ключ называется суррогатным. Не стоит делать его первичным (пусть будет вторичным)
2) Искусственный ПК.
2.1) Счетчики и Автоинкременты. В базах MS Jet (то бишь Access) они обладают единственным недостатком - их нельзя изменить, однако, как тут уже заметили, это внутренние данные, которые конечному пользователю вообще не должны показываться, а следовательно, и не возникает необходимости в их изменении. За динамический диапазон типа Длинное целое можете не беспокоиться - разрядности хватит для любой прикладной задачи. Чтобы исчерпать Longint вам потребуется раз в секунду добавлять записи на протяжении более 130 лет!
2.2) GUID (В Access он называется Код репликации). Надо использовать если копии базы (реплики) будут раздаваться агентам, работающим независимо друг от друга, чтобы обеспечить уникальность ключей и возможность синхронизации баз агентов с единой централизованной базой.

Dr_Grizzly · 30 апр 2007, 15:39

&quot писал(а):2.2) GUID (В Access он называется Код репликации). Надо использовать если копии базы (реплики) будут раздаваться агентам, работающим независимо друг от друга, чтобы обеспечить уникальность ключей и возможность синхронизации баз агентов с единой централизованной базой.

Во-во-во! Можно тут по подробнее! В моем случае постронение по суррогатным ключаем решает проблему объединения нескольких баз в одну. Т.е. на нескольких машинах люди забивают информацию в однинаковые по структуре базы. Каждый месяц я эти базы объединяю в одну и у меня нет накладок со связями при таком построении. Дак вот, как граммотно построить GUID ключ? И как с ним общаться в коде.