Autonumber vs. Text String для первичного ключа?

Я пытаюсь найти лучшее решение проблемы, с которой я только что столкнулся. Я ненавижу делать что-то без понимания, поэтому я надеюсь, что кто-то может помочь.Autonumber vs. Text String для первичного ключа?

У меня есть база данных Access со столом, в котором хранится информация об отеле, а затем другая таблица, в которой хранятся маршруты. Таблица маршрутов выберет из списка отелей в отеле Hotels.

Я хочу установить правильные отношения, но использование первичного ключа Autonumber в таблице отелей, который соединяется с полем «Отели» в таблице маршрутов, не будет работать. (., Потому что Autonumber ID не совпадают с названиями гостиниц)

Что лучше:

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

B. Измените элемент управления дисплеем в поле «Отели» в таблице «Маршруты» на поле со списком, в котором перечислены первичный ключ «Номер», а также скрывается. Вместо этого он показывает колонку с названиями гостиниц. Я нашел это решение здесь: http://www.trigonblue.com/accesslookup.htm

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

Мне очень хотелось бы найти неправильный ответ здесь и иметь проблемы в будущем.

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

Спасибо!

источник

2016-09-17 arbitel

Вы можете добавить связь между отелями и маршрутами, используя отель ID - просто добавьте индексированный длинный fiedl «HotelID» на маршруты с «Разрешить Дубликаты» - гораздо лучше, чем ссылки на имена отелей – dbmitch

Спасибо за ваш ответ , Извините, что я новичок и, возможно, не понимаю - не будет ли идентификатор отеля номером на поле Маршруты? Я не знаю, какие AutoNumbers соответствуют номерам отелей – arbitel

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

Auto-number - это самый эффективный способ настройки Первичного ключа, это наименьшая работа для СУБД для поиска, чтобы найти то, что она ищет. Это особенно актуально, если вы будете иметь отношения первичного/внешнего ключа в своих таблицах.

Не говоря уже о том, что есть преимущества для этого в целях хранения и индексирования (неважное дело в Access, но на других оно будет).

источник

2016-09-17 22:32:30

Спасибо за ваш ответ - так вариант B лучший здесь? Или есть другой способ, которым я все еще могу использовать Autonumber для установления отношений? – arbitel

Не знаете, почему вы думаете, что «решение B становится перепутано, если в таблицу вставлены новые поля.» «Это правильный способ сделать это - и вы просто меняете свой поле со списком, чтобы сортировать имя отеля - ничто не запутано на дисплее. Вы все равно можете добавить индекс в название отеля, чтобы ускорить сортировку, если вы хотите – dbmitch

Единственное, что с этим решением - вы выбираете количество столбцов и ширину столбца. Итак, скажем, что ключ - столбец 1, а нужный вам экран - столбец 2. Вы установили инструмент поиска в 2 столбца и установили ширину в 0 "; 1". Если вы вставили новое поле перед вторым столбцом, это будет отображаться вместо этого. Я имею в виду, я думаю, я не мог забыть вставить поле, но похоже, что должен быть лучший способ. – arbitel

Вы почти никогда не должны использовать имя в качестве Первичного ключа. Использование уникального идентификатора в форме CODE или ID - это гораздо более безопасный подход. Отказ от использования имени позволяет:

Аннотация название от идентификатора
магазина имя в одном месте
Измените имя, если требуется, в одном месте
Используйте меньше дискового пространства и памяти.
Выполнять более быструю индексацию, вставляет, удаляет, объединяет, сортирует и группирует.

Иногда у вас уже есть код или идентификатор, или вы ограничены внутренним/внешним правилом, но большую часть времени ключевой ключ AutoNumbered очень полезен.Это:

Числовой, поэтому она хранится эффективно
Numeric, так быстро работать с
Гарантированная быть уникальным
Новые записи всегда вставить в конец таблицы и требуют минимальных усилий для перемещения страниц или изменений индекса.

источник

2016-09-18 08:06:12 ThunderFrame

«Гарантировано быть уникальным» - ну, автонабор можно вернуть до 1, чтобы новые строки генерировали дубликаты. Кроме того, вы можете обновить столбец с атрибутом autonumber для создания дубликатов. Гарантия, которую вы требуете, предназначена исключительно для Первичного ключа и не имеет отношения к AutoNumber. – onedaywhen

За исключением этого доступа. Мессинг с семенем возможен с использованием DDL, но [НЕ рекомендуется] (http://superuser.com/questions/288087/how-do-i-set-the-first-value-of-autonumber-in-access # comment301363_288087) – ThunderFrame

«Новые записи всегда вставляются в конце таблицы» - То же самое можно сказать о любой таблице, независимо от того, был ли у нее автономер и/или первичный ключ. Я думаю, вы имеете в виду, что если autonumber является инкрементным (не случайным), и максимальное значение не было достигнуто, то когда файл сжимается, физический порядок на диске не изменяется, поскольку PK диктует кластеризованный индекс. Это сомнительное преимущество, потому что часто возникают споры по наиболее недавно созданным строкам: если они находятся на одной физической странице, тогда вы можете столкнуться с проблемами блокировки. Случайный автозапуск может быть лучше. – onedaywhen

Autonumber vs. Text String для первичного ключа?

ответ

Смежные вопросы