建設プロジェクトの在庫管理システムを開発しています。店主は、新しい在庫を追加し、従業員に/から配布/返却する責任があります。アイテム (およびその属性) は非常に多様です。例: 製鉄所、衣料品、工場/機械、工具など
私の質問は、クラス/具象テーブルの継承または EAV ベースのスキーマのどちらを使用するかです。項目にどのような属性が含まれるかはわかりません。そのため、おそらくクラス/具体的なテーブルの継承アプローチでは、エンド ユーザーが新しいテーブルをデータベースに追加する必要があります (これは可能ですか?)。
私の提案するEAV スキーマを参照してください。これは合理的な解決策でしょうか？在庫品目を識別するには、「EV」テーブルのクエリで複数の自己結合を実行する必要があると言っているのは正しいと思いますか?
NB PHP、MySQL、および Zend Framework を使用した開発。
属性の変更がほとんどない場合は、テーブルの継承に進みますが、スキーマへの変更は自分または DBA が行う必要があります。ユーザー入力に基づいてスキーマをプログラムで変更することは、悪い考えのように思えます。
属性の変更が頻繁に行われる場合は、MongoDBやCouchDBなどのドキュメント指向データベースの使用を検討してください。
属性の変更が一般的で、リレーショナル データベースに制限されている場合は、EAVを使用してください。
何千もの製品を含む医療リポジトリを構築しない限り、EAV は避けます。クラス テーブルの継承は適切な解決策であり、実行時にスキーマを変更することはそれほど悪い考えではありません。
さまざまな属性を持つさまざまな製品があるオンライン ショップを構築しているとします。通常、製品は一連の属性を使用しています。クラス テーブル継承パターンを使用すると、製品セットごとに 1 つのテーブルを作成し、共通の製品属性を持つ共通テーブルを継承できます。新しい属性が必要な場合、次の 2 つのオプションがあります。
実行時にテーブルを変更すると、変更中にロックが発生するため、実際に問題が発生する可能性があります。ただし、MySQL 5.6 では、プログラマは LOCK タイプ、つまり LOCK=NONE および ALTER ONLINE|OFFLINE を指定できます。明らかに、DB ベンダーは、実行時にデータベースを変更できるようにするために、この方向に取り組んでいます。
テーブルのロックの問題も回避/最小化できます。ロックの問題は通常、巨大なテーブル、つまり 100k 以上のレコードを変更するときに発生します。ただし、継承により、異なるセットで製品を配布できるため、テーブルごとのレコードの量が比較的少なくなります。
たとえば、10 種類の製品がある場合、10 種類のテーブルがあります。タイプごとに 10,000 個の製品があると仮定します。これは、100,000 個を超える製品があることを意味しますが、セットに新しい属性を追加すると、10,000 行のみのテーブルに新しい列が追加されます。1 万行のテーブルに新しい列を追加するのに 1 秒もかからないのに、実行時にクラス テーブルの継承を処理するときにデータベース スキーマを変更するのは本当に悪い考えでしょうか?
この点について、より多くの意見をお聞かせいただければ幸いです。みんなありがとう。
