БД: Использовать тождественный столбец или нет?

Question

При разработке таблицы мой коллега говорит, что мне следует избегать столбца идентификаторов, поскольку он специфичен для SQL Server и MS Access, но я не согласен с его представлениями, поскольку это упрощает мое кодирование.

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

Answer 1

Вы не можете полностью отделить приложение от поставщика базы данных. Если вы это сделаете, вы не сможете воспользоваться всеми функциями, которые предоставляет вам ваша база данных.

Я бы сказал, используйте столбец идентификации. Если вы перейдете к Oracle (например), вы можете использовать Sequence. Вряд ли большое изменение.

Я не знаю, какую технологию вы используете, но одна вещь, которая могла бы помочь, - это использование инструмента, такого как Hibernate или iBATIS (я думаю, что они оба доступны для Java и .NET), который немного отличает вас детали реализации базы данных. Тогда, если вы смените поставщика базы данных, вам не нужно будет менять код приложения, просто настройку. (По крайней мере, теоретически!)

Answer 2

Использовать столбец идентификаторов!

Это отделяет вашу «Прикладную логику» от «Бизнес-логики».

Допустим, вы используете «электронную почту» в качестве первичного ключа (что имеет смысл с точки зрения «бизнес-логики»). Вы столкнетесь с проблемами, когда этого письма больше не будет, и ваш пользователь захочет изменить ваше письмо.

Answer 3

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

1. Access и SQL Server имеют идентификационные столбцы
2. MySQL имеет столбцы с автоинкрементом
3. PostgreSQL имеет последовательности
4. sqlite имеет неявный столбец ROWID
5. У Oracle есть какая-то последовательность, хотя я совсем не знаком с ней

Я в основном использую его, теоретически это не всегда требование, но если вы хотите сохранить ссылочную целостность, int хранить меньше и его легче сравнивать, чем varchar, особенно если ваши внешние ключи будут более сложными, чем один столбец.

Answer 4

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

Последовательности гораздо более гибкие и не имеют недостатков / ограничений, которые имеют столбцы Identity.

С http://www.jumpingbean.co.za/blogs/mark/identity_autoincrement_fields_and_database_sequences:

Боль с автоинкрементом

Копирование данных во время сохранение значения идентичности

Автоинкрементные клавиши могут стать боль, когда вам нужно скопировать весь табели и сохранить первичный ключ значение. Попытка вставить прямо в столбец идентичности приведет к ошибка поднимается. Типично поставщик предоставляет некоторые заявления, которые позволяют временно отбросить ограничение, чтобы вы могли вставить существующие ценности. В MSSQL вы можете оформить Команда

"УСТАНОВИТЬ IDENTITY_INSERT Продукты ВКЛ".

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

Больше боли - как получить значение недавно вставленные строки?

Кроме того, сервер обычно предоставляет различные способы получения значение столбца идентичности для нового вставленный ряд Для MySQL это Функция LAST_INSERT_ID () и для MSSQL это @@ identity, например, select @@ IDENTITY.

MS SQL Server 2011 будет поддерживать ПОСЛЕДОВАТЕЛЬНОСТЬ.

Если вы используете сервер RDBMS, который не поддерживает SEQUENCE (например, MSSQL до 2011 года или MySQL), есть две альтернативы:

1. Переключиться на PostgreSQL . На самом деле это самый простой вариант. Вы получаете корпоративный RDBMS-сервер с полностью открытым исходным кодом. И вы можете получить коммерческую поддержку, если хотите.
2. Используйте библиотеку доступа к данным, которая поддерживает эмуляцию SEQUENCE . JPA 2.0 реализации, например. EclipseLink , Hibernate сделать это очень тривиально для вас (стратегия TABLE) . Это не является взаимоисключающим с вышесказанным. Использование JPA 2.0 с PostgreSQL сделает вашу жизнь намного проще, чем, скажем, сырой JDBC с MySQL.