2012-03-17 4 views
0

解決を求める問題をフレーズするために、以下のテーブルとJavaクラスを検討してください。 -リレーションシップのクラス設計

カラムid、nameを持つCITYテーブル。 Javaクラスidとnameプロパティを持つ都市。

カラムid、nameを持つCOUNTRYテーブル。 Javaクラスidとnameプロパティを持つ国。

カラムid、name、city_id、country_idを持つUSERテーブル。ここで、city_idはCITYテーブルのFKであり、country_idはCOUNTRYテーブルのFKです。 Javaクラスid、name、cityId、およびcountryIdプロパティを持つユーザー。

ユーザーIDに表示される名前の代わりにユーザーのレコードのcityIdとcountryIdを表示することはできません。私のUserクラスの設計は正しいですか?どのようなデザインが必要ですか? cityIdとcountryIdではなく、CityオブジェクトとCountryオブジェクトでなければなりませんか?また、どのように必要なデータをロードする必要がありますか?

テーブルに列が増えている複雑なシステムでも同じことを想像してください。どのように複雑なシステムの設計規模は?私はオブジェクト全体を必要としないので、ほとんどの場合、名前だけで十分です。

答えて

1

まず、あなたのデザインは正しいとは言えません。市はある国に属していなければならず、ユーザーの国は都市を通じてアクセス可能であるため、ユーザーは国を直接参照する必要はありません。

しかし、メモリの使用に対処するには、さまざまなオプションがあります。多くの場合、数字を見ると都市や国の総数はそれほど多くないので、単にオブジェクトへの直接リンクを使用できます。私は、これらの種類の "関連情報"クラスが連続してメモリに保持されるアプリケーションを持っています。重要なデータ(人のような)を読み書きするときの解約量が減ります。

代わりに、市区町村名と国名を文字列として結合して、読み込み時に読み込まれる個別の(読み取り専用の)場所属性(変更不可能またはディスクに書き込まれない)でユーザークラスを拡張できます。あなたはその人物を読んで、そのフィールドにデータを入力しますが、都市や国のオブジェクトに(または怠け者にして)人口を埋めるわけではありません。すべてのオブジェクトをメモリにロードせずに表示するデータを提供します(ただし、文字列のメモリコストはまだあります)。

あなたが本当にスペースのためにプッシュされている場合は、場所の取得をディスプレイ自体の一部にし、ディスプレイに表示されている人々の場所を取得して表示するだけです。しかし、これはうまくいく多くの仕事です。

関連する問題