2 Stimmen

ISBNs werden als Primärschlüssel verwendet, jetzt möchte ich der DB Dinge hinzufügen, die keine Bücher sind - sollte ich zu EAN migrieren?

Ich habe eine Bestandsdatenbank erstellt, in der ISBN-Nummern die Primärschlüssel für die Artikel sind. Das hat eine Zeit lang gut funktioniert, da es sich bei den Artikeln um Bücher handelte. Jetzt möchte ich Nicht-Bücher hinzufügen. Einige der Nicht-Bücher haben EANs oder ISSNs, einige nicht.

Es ist in PostgreSQL mit django Anwendungen für das Frontend und JSON api, plus ein paar unterstützende Python-Befehlszeilen-Tools für die Verwaltung. die Artikel in Frage sind vor allem Bücher und Künstler Drucke, von denen einige selbst veröffentlicht werden.

Was ist schön über die Verwendung von ISBNs als Primärschlüssel ist, dass auf der relationalen Integrität, erhalten Sie viele praktische Dienstprogramme für die Validierung von ISBNs, automatisch suchen fehlende oder zusätzliche Informationen über die Buch-Elemente, etcetera, von denen viele, die ich genutzt habe. einige solche Werkzeuge sind off-the-shelf (PyISBN, PyAWS etc.) und einige sind handgerollt - ich habe versucht, alle diese Teile schön und entkoppelt zu halten, aber Sie wissen, wie die Dinge bekommen kann.

Ich konnte online nichts über "private ISBNs" oder "selbst zugewiesene ISBNs" finden, aber das ist genau das, was mich interessiert. Ich bezweifle, dass ich mich dafür entscheiden werde, da es bereits einen offensichtlichen Run auf ISBN-Nummern gibt.

Sollte ich alles für EAN-Nummern umrüsten oder ISBNs als Primärschlüssel generell abschaffen? Wenn jemand Erfahrung mit der Arbeit mit diesen Systemen hat, würde ich gerne davon hören, Ihr Rat ist höchst willkommen.

3voto

the_lotus Punkte 12421

Ich kenne Postgres nicht, aber normalerweise wäre ISBM ein eindeutiger Indexschlüssel, aber nicht der Primärschlüssel. Es ist besser, eine ganze Zahl als Primär-/Fremdschlüssel zu verwenden. Auf diese Weise müssen Sie nur ein neues Feld EAN/ISSN als nullable hinzufügen.

3voto

gbn Punkte 407102

Ich stimme the_lotus zu, nicht zuletzt weil ISBN eine schlechte Wahl für den Primärschlüssel ist

Was die Daten betrifft, so sind sie möglicherweise nicht eindeutig genug. Wenn sie geclustert ist, ist sie ziemlich breit und nicht numerisch

Ejemplo

2voto

Isaac Punkte 10250

Wenn Sie ISBN-10s verwenden, sollten Sie auf jeden Fall auf etwas anderes umsteigen, da diese bereits veraltet sind. Sie können ISBN-10s ganz einfach in ISBN-13s umwandeln (siehe wikipedia ), die meines Erachtens EAN-kompatibel sind (siehe auch wikipedia ), aber wie the_lotus vorschlägt, ist es wahrscheinlich besser, eine Art automatisch inkrementierende Ganzzahl ohne externe Bedeutung als Primärschlüssel zu haben und dann einen Index auf EAN/ISBN/etc.

0 Stimmen

Im Augenblick unterstütze ich entweder ISBN-10 oder ISBN-13 - es ist, was auch immer der Barcode-Scan der Bücher zeigt, oder was auf dem Umschlag oder der Klappe für ältere Ausgaben gedruckt wird. es wandelt die Zahl in die ISBN-13 Variante für einige 3rd-Party-API-Lookups wie nötig um. Sie sind richtig w/r/t EAN-Kompatibilität tho, weshalb ich an der potenziellen Migration zu EAN insgesamt interessiert bin.

2 Stimmen

Ein Teil meines Zögerns, EAN als Primärschlüssel zu empfehlen, besteht darin, dass ich nicht sicher bin, ob es garantiert eindeutig pro Produkt ist - UPC-Codes, die eine Teilmenge von EAN sein sollen, sind nicht immer eindeutig pro (Lebensmittel-)Produkt.

0 Stimmen

Das ist in der Tat gut zu wissen. Ich gehe mit Integer-Schlüssel für jetzt, danke.

1voto

Joshua D. Drake Punkte 996

Eine einfache Lösung (auch wenn es fraglich ist, ob sie gut ist) wäre die Verwendung von (isbn,title) oder (isbn,author), was die Eindeutigkeit so gut wie garantieren sollte. Ideologie ist großartig, aber Praktikabilität dient auch einem Zweck.

0 Stimmen

Ich bin selbst ein großer Fan der Praktikabilität - aber leider wären Sie überrascht, wie unterschiedlich die verschiedenen buchbezogenen Datenquellen (Amazon, Openlibrary, Isbndb u.a.) vorgehen, wenn es darum geht, wie Felder wie "Autor" oder "Titel" formatiert und normalisiert werden - der Umgang damit kann ziemlich heikel sein, und es wäre noch heikler, die Integrität der Datenbanken darüber hinaus vorauszusetzen.

CodeJaeger.com

CodeJaeger ist eine Gemeinschaft für Programmierer, die täglich Hilfe erhalten..
Wir haben viele Inhalte, und Sie können auch Ihre eigenen Fragen stellen oder die Fragen anderer Leute lösen.

Powered by:

X