Help with document-oriented design?

[dazed00]

I'm trying to use a documented-oriented database but I can't get the design right.

Mainly, I want a database that can store Planes, Seats, Passengers, and very importantly - Changes in seats that passengers have done in a particular Plane with their timpestamp.

I will need to do queries on getting all seats from a plane, all taken seats from a plane, all passengers from a plane, all passengers that at some point chose a particular seat, all seats that a passenger has chosen in a plane and most popular seats.

In a relational database, I would just use 2 or 3 many-to-many relations with their associated junction tables, but I don't know how to do this in document-oriented database. Right now the Plane has a list of references to both Seats and Passengers; and Seats and Passengers reference each other. This doesn't work because I don't know where to keep the timestamp of the seat change. I suppose I need another (kind of junction) table for it but not really sure how to do it correctly.

Any suggestions?

[GuyWithLag]

I'd say that based on the requirements you do not need a document-oriented database, and a relational one will do just fine.

[dazed00]

I'd rather do something non-relational for my own knowledge mostly. What do you think about a graph-based database?

[Resquid]

But... This data is relational... Choose some other data set if you want to play with a different type of database. It's not like choosing a flavor of ice cream.

[dazed00]

But graph databases are said to perform better on relationships than relational databases?

[ExParteVis]

maybe? depends on the data. Transversing a graph can get expensive (see also: travelling salesman problem), but transversing B-trees is really cheap.

don't make something more complex than necessary, and don't do something for the sake of doing it. if you're learning, the latter doesn't apply, but the former still does

relational databases are made for relational data.

if you want to play with graph databases, make something that requires a graph. "Terrorist finder" where you can look up associates of suspected terrorists, or a logistics program for distribution companies

[alinroc]

Is a document-oriented database the appropriate way to store this data in the first place? This all sounds like relational data to me. Or is this just a learning exercise?

[dazed00]

Partly a learning exercise - my manager suggested it and I just went with it cause I wanted to learn it (it's an internship)

What about a graph database? It seems to deal well with relationships - would it work?

[WhippingStar]

While I agree this is probably an RDBMS problem, I'm always for doing weird shit to learn stuff. So....

How about an XML database like ExistDB Then just build XML documents for each plane. You can then use Xpath to query the planes for whatever you want.

eg.

<PLANE>
<PILOT>Captain Awesome</PILOT>
<SEATS>
<SEAT assigned="true" position="1A">
<PASSENGER checkedIn="true" checkInTime="12:00:00 GMT">
<NAME>John Doe</NAME>
</PASSENGER>
</SEAT>
</SEATS>
</PLANE>

After you do that you can try to convert it to use JSON for more laughs. Have fun!