ISBN используются в качестве первичного ключа, теперь я хочу добавить в БД вещи, не относящиеся к книгам. Следует ли мне переходить на EAN?

Я создал базу данных инвентаря, в которой номера ISBN являются первичными ключами для предметов. Какое-то время это прекрасно работало, так как предметами были книги. Теперь я хочу добавить не-книги. у некоторых некниг есть EAN или ISSN, у некоторых нет.

Это в PostgreSQL с приложениями django для внешнего интерфейса и JSON API, а также с несколькими вспомогательными инструментами командной строки python для управления. рассматриваемые предметы в основном представляют собой книги и репродукции художников, некоторые из которых изданы самостоятельно.

Что хорошо в использовании ISBN в качестве первичных ключей, так это то, что помимо реляционной целостности вы получаете множество удобных утилит для проверки ISBN, автоматического поиска отсутствующей или дополнительной информации об элементах книги и т. д., многими из которых я воспользовался. . некоторые такие инструменты уже готовы (PyISBN, PyAWS и т. д.), а некоторые создаются вручную — я старался, чтобы все эти части были красивыми и несвязанными, но вы знаете, как все может получиться.

Я не смог найти в Интернете ничего о «частных ISBN» или «самостоятельно присваиваемых ISBN», но мне было интересно этим заниматься. Сомневаюсь, что я остановлюсь на этом, так как уже есть очевидный пробег по номерам ISBN.

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


python django postgresql isbn
person fish2000    schedule 09.04.2010    source источник

Ответы (4)


arrow_upward
2
arrow_downward

Если вы используете номера ISBN-10, вам определенно следует перейти на что-то другое, так как они уже устарели. Вы можете легко преобразовать ISBN-10 в ISBN-13 (см. википедию), что Я думаю, что они совместимы с EAN (опять же, см. википедию), но, как предполагает the_lotus, это, вероятно, лучше иметь какое-то автоинкрементное целое число без внешнего значения в качестве первичного ключа, а затем индексировать EAN/ISBN/и т. д.

person Isaac    schedule 09.04.2010
comment
прямо сейчас я поддерживаю либо ISBN-10, либо ISBN-13 - это то, что показывает сканирование штрих-кода книги или то, что напечатано на обложке или клапане для более старых изданий. при необходимости он преобразует номер в вариант ISBN-13 для некоторых сторонних API-запросов. вы правы в отношении совместимости с EAN, поэтому я заинтересован в потенциальном переходе на EAN в целом. - person fish2000; 09.04.2010
comment
Часть моего нежелания рекомендовать EAN в качестве первичного ключа заключается в том, что я не уверен, гарантированно ли он будет уникальным для каждого продукта — коды UPC, которые должны быть подмножеством EAN, не всегда уникальны для каждого (пищевого) продукта. - person Isaac; 09.04.2010
comment
действительно, это хорошо знать. Сейчас я использую целочисленные ключи, спасибо. - person fish2000; 09.04.2010

arrow_upward
3
arrow_downward

Я не знаю postgres, но обычно ISBM будет уникальным ключом индекса, но не основным. Лучше иметь целое число в качестве первичного/внешнего ключа. Таким образом, вам нужно только добавить новое поле EAN/ISSN как обнуляемое.

person the_lotus    schedule 09.04.2010

arrow_upward
3
arrow_downward

Я согласен с the_lotus, не в последнюю очередь потому, что ISBN — плохой выбор для первичного ключа.

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

Пример

person gbn    schedule 09.04.2010

arrow_upward
1
arrow_downward

Простым решением (хотя, возможно, и хорошим) будет использование (isbn,title) или (isbn,author), что в значительной степени гарантирует уникальность. Идеология — это хорошо, но практичность тоже служит цели.

person Joshua D. Drake    schedule 10.04.2010
comment
Я сам большой поклонник практичности, но, к сожалению, вы будете удивлены разнообразием подходов, используемых различными источниками данных, связанными с книгами (amazon, openlibrary, isbndb и др.), с учетом того, как такие поля, как «автор ' или 'title' отформатированы и нормализованы - иметь дело с этим может быть довольно рискованно, и было бы еще опаснее предполагать целостность баз данных поверх этого. - person fish2000; 13.04.2010