2

ISBN番号がアイテムの主キーである在庫データベースを構築しました。アイテムが本だったので、これはしばらくの間うまくいきました。今、私は非本を追加したいと思います。非書籍の中には、EANまたはISSNを備えているものと、備えていないものがあります。

これはPostgreSQLにあり、フロントエンド用のdjangoアプリとJSON apiに加えて、管理用のPythonコマンドラインツールをいくつかサポートしています。問題のアイテムは主に本とアーティストの版画であり、そのうちのいくつかは自費出版です。

ISBNを主キーとして使用することの良い点は、リレーショナル整合性に加えて、ISBNを検証したり、書籍のアイテムなどに関する不足している情報や追加情報を自動的に検索したりするための便利なユーティリティがたくさんあることです。 。そのようなツールの中には既製のもの(PyISBN、PyAWSなど)もあれば、手作業で巻いたものもあります。これらすべてのパーツを適切に分離して維持しようとしましたが、どのようにすればよいかはご存知でしょう。

「プライベートISBN」や「自己割り当てISBN」についてはオンラインで何も見つかりませんでしたが、それは私が興味を持っていたようなものです。ISBN番号にはすでに明らかな実行があるので、それが私が解決することになるとは思えません。

EAN番号用にすべてを再構築する必要がありますか、それとも一般的に主キーとしてISBNから移行する必要がありますか?誰かがこれらのシステムを使った経験があるなら、私はそれについて聞いてみたいです、あなたのアドバイスは大歓迎です。

4

4 に答える 4

3

私はthe_lotusに同意します。特に、ISBNは主キーには不適切な選択であるためです。

データに関しては、十分に一意ではない可能性があります。クラスター化されている場合、それは非常に広く、数値ではありません

于 2010-04-09T19:15:15.693 に答える
3

postgresはわかりませんが、通常、ISBMは一意のインデックスキーですが、プライマリではありません。主キー/外部キーとして整数を使用することをお勧めします。そうすれば、新しいフィールドEAN/ISSNをnull許容として追加するだけで済みます。

于 2010-04-09T18:58:46.490 に答える
2

ISBN-10を使用している場合は、すでに非推奨になっているため、他の何かに移行する必要があります。ISBN-10を簡単に取得してISBN-13に変換できます(ウィキペディアを参照)。これはEAN互換だと思います(ここでもウィキペディアを参照)が、the_lotusが示唆しているように、ある種の自動インクリメント整数を使用する方がおそらく良いでしょう。主キーとして外部的な意味を持たず、EAN / ISBN/etcのインデックスを作成します。

于 2010-04-09T19:03:44.530 に答える
1

単純な解決策(おそらく良いかどうかはわかりますが)は、(isbn、title)または(isbn、author)を使用することであり、これにより、一意性がほぼ保証されます。イデオロギーは素晴らしいですが、実用性も目的を果たします。

于 2010-04-10T16:17:09.993 に答える