0

Journey というテーブルに STI を使用しています。人々は旅行のリクエスト/オファーを投稿するため、Discriminator は Driver または Passenger のいずれかになります。つまり、運転して他の乗客を連れて行くことをいとわない人、または単にヒッチハイクしている人 (乗客) によって投稿された旅行があることを意味します。したがって、これら 2 つはほとんどの属性 (出発日、ソース、目的地など) を共有しますが、投稿しているユーザーのタイプが原因で名前の衝突が発生します。

たとえば、私が乗客の場合、友人と一緒に旅行したいと指定できます (つまり、PassengerCount = 2 となります。つまり、空席が 2 つ以上あるドライバーを探します)。または、荷物を持っていきたい (つまり、HaveLuggage = true、つまり、荷物を持って行ける乗り物を探している) ことに気付くかもしれません。

一方、私が運転手であれば、利用可能な座席数 (AvailableSeats) を指定できるフォームに入力する必要があります。荷物を運ぶことができない (TakesLuggage=false) ことに注意する必要があります。

PassengerCount - AvailableSeats 列と HaveLuggage - TakesLuggage 列は同じですが、ポスターの観点からは名前だけが異なります。

問題は、混乱を最小限に抑えるために、どの命名規則に従うべきかということです。また、このようなテーブル (STI) を 1 つ用意することは良い考えですか? そうでない場合は、どの代替案をお勧めしますか?

4

1 に答える 1

0

命名規則についてそれほど心配する必要があるかどうかはわかりません...あなたはすでに識別プロパティ（タイプ）を持っています。好きなように区別できるラベルをデータ出力に追加できます。例：

Journey
   Type (integer) -- 1 = provider, 2 = consumer
   Passengers (integer)
   Luggage (bit / bool) -- 1 = yes, 0 = no

命名規則について：

SELECT "Driver", passengers as "Avaliable Seats", luggage as "Takes Luggage" WHERE type=1
UNION
SELECT "Passenger", passengers as "Passenger Count", luggage as "Have Luggage" WHERE type=2

または、SELECT自体で制御ステートメント（IF / CASE / etc）を使用することもできます。

于 2013-02-21T16:19:47.807 に答える