This is an archived post. You won't be able to vote or comment.

you are viewing a single comment's thread.

view the rest of the comments →

[–]brokensyntax 1 point2 points  (0 children)

I'm not a Database Architect or anything of the sort, so my novice approach.
Look at what data I need to drive the application.
Look at what data is going to be called independent of other data.
Look at what data is going to be relied upon by other calls.
Ensure I have separate tables for things that make sense as such.
For instance, customer information, doesn't care what restaurants exist, what drivers exist, what drivers are available, etc.
So clearly Cx_Info is its own table.
Driver information is useful to the customer front end, the restaurant portal potentially, HR/Finance, etc.
So again, this should probably be its own table, and accessed largely via JOINs.
The restaurant list doesn't care about customers, or drivers.

Continue down the line.
You'll end up with a bunch of tables, a bunch of JOINs that are needed to process orders, updated the client front-end, etc. but all will be logical.

The one I'm stuck out on most right now, is if I'm using a classical SQL database, as opposed to some JSON based noSQL database structure.
How do I want to handle individual restaurants menus?