データベース設計の混乱とその解決方法

データベース設計に関する混乱
状況はこんな感じです。以前Webサイトを構築していた時、「おすすめ」や「トップ」などが出てくると、必ず「IsTop」や「IsDelete」などのフィールドをテーブルに追加していました。 " などの場合は BOOL 型を使用します。しかし、私が最近新しい会社に来たとき、会社のリーダーたちはこれをしませんでした。例: 「IsTop」は削除するかどうかを示すため、news_delete テーブルを作成し、その中のレコードは「IsTop」の ID 値になります。

これは良いアイデアで、とても使いやすそうです。同様のものを追加する場合、元のテーブルを変更する必要はありません。データベース設計の専門家にどうすればよいかを聞きたいです。

-----解決策--------------------------------
データを感じられれば大丈夫です 構造が複雑な場合は、2番目の方法に従って設計し、分割すれば大丈夫です。
------解決策---------
寛容になることを学びましょう
あなたの説明として、特定のルールはありません

追加の属性は基本データと密接に関連しています
明らかに、あなたのソリューションは分割テーブル ソリューションよりも優れています
------解決策----------------------
フィールドをカスタマイズする 2 つの方法、1 つは追加する方法です。もう 1 つは、値を保存するためのカスタム フィールド テーブルを作成することです。個人的には、後者はステートメントがやや複雑で、検索が不便で、結合操作が必要になります。前者は単純かつ乱暴で、検索用のインデックスを設定するのに便利ですが、両方のオプションを保持し、特定の問題に対して特定の方法を実装するのが最善です。
------解決策---------

話し合う

引用:
許容誤差を学習します
説明に特定のルールはありません

追加の属性は基本データと密接に関連しています
明らかに、あなたのソリューションはより優れていますサブテーブル ソリューション


つまり、私のソリューションは効率とパフォーマンスが良く、使いやすいということですね。それは正しい。

------解決策---------

話し合う

引用:
フィールドをカスタマイズするには 2 つの方法があります。1 つはこのテーブルにフィールドを追加する方法、もう 1 つは値を保存するカスタム フィールド テーブルを作成する方法です。個人的には、後者はステートメントがやや複雑で、検索が不便で、結合操作が必要になります。前者は単純かつ乱暴で、検索用のインデックスを設定するのは便利ですが、両方のオプションを保持し、特定の問題に対して特定の方法を実装するのが最善です。

foolbirdflyfirst には...

------解決策------------------
問題は解決したので投稿を閉じます。債券金利を見てください。 0% 投稿: 7 通常投稿: 0