11

Initially I would like to ask you to forget about hashing passwords or w/e related to passwords, this question is not related to securing passwords, etc and I do know/understand how this should be done.

What is the best approach to store the data in question, considering performance on read/write - to build one or more tables?

Single table, for example:

Table users: id, username, password, hash, email, group, access, address, phone, parents, ts_created, ts_update

Multiple tables, for example:

Table users: id, username, password, hash, email, group, access, ts_created, ts_update

Table user's information: id, user_id, address, phone, parents, ts_created, ts_update

What if your user's information fields may grow along the time - how should you deal with it ?

For example new fields: birthday_date, comments, situation

Will having 2 tables be slower on queries than having a single table ?

If having multiple tables in this case is only for maintaining a good design with separated data, does that mean it is not useful at all for performance reasons ?

If you want real sql examples let me know and I will scrap something to update this.

4

2 に答える 2

5

保存するデータによっては、さらに多くのテーブルが必要になる場合があります。

  1. ユーザーが以前に使用したパスワードを再利用できない将来、パスワードポリシーを使用するとどうなりますか？
  2. ユーザーは複数の電子メールを持つことができますか？
  3. ユーザーは複数のグループに属することができますか？
  4. ユーザーは複数の電話番号を持つことができますか？
  5. たった一人の親？または2つ？親はシステムにいますか？親についてどのような情報を保存していますか？

このように保存することは、それ自体の個別のテーブルに保存する価値があるかもしれないと考えています。つまり、将来的には、保守がはるかに簡単になるはずです。システムがどのように変化するかを考える必要があります。パフォーマンスに関しては、すでに概説したように、正しいインデックスを作成し、データベースを正しく使用する限り、問題はありません。

于 2010-06-29T08:44:19.847 に答える
4

複数テーブルの設計は賢明に見えます。1つのテーブルにはユーザーに関するデータが含まれ、もう1つのテーブルには個人に関するデータが含まれます。ユーザーデータのみが必要な場合（アクセス権の確認など）、個人データは関係ありません。

提案する新しいフィールドは、おそらく新しい列としてpersonテーブルに入ります。

2つ（またはそれ以上）のテーブルを使用してそれらを結合しても、パフォーマンスが大幅に低下することはありません。パフォーマンスが向上する可能性もあります（適切なインデックス付けを使用すると、user_idの一意のインデックスがここから開始するのが適切です）。

  • SELECTでは、速度の違いはごくわずかです。
  • INSERT / UPDATEでは、これはほとんどの状況で単一のテーブルよりも優れています（たとえば、「users」テーブルに多くの読み取りがある場合、人への書き込みはそれらをブロックしません-一方、1つのテーブルでは発生する可能性があります）

また、個人的には、単一の幅の広いテーブルよりも2つの幅の狭いテーブルを使用する方がはるかに簡単です（コードとデータベース管理の両方で）。

于 2010-06-29T08:29:18.260 に答える