Databases
StackOverflow2013
Postsdbo
PO
 

Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    primarykey
    data
    text
    <p>I think this depends on how you want to interact with the data. The benefit of the second approach is that it's easy to see which categories and statuses are associated with a specific object (vendor, item, order). Keep in mind that if you do use the first approach you will probably have to have a type identifier in your categories and status tables to identify the kind-of category or status the row is related to (vendor, item, order).</p> <p>The benefit of the first approach is that it's easier to add statuses and categories for new objects, and there is a simplicity in only having two tables. The problem arises when you want to add additional information to a specific category or status. For example, if order statues need to have an effective_date, but item statues should not have an effective_date. Once you reach this point you'll either have to move to the second approach or add an effective_date that will be null for the other statuses to which the attribute does not apply.</p> <p>Keep in mind that another approach would be to not create statuses and categories tables at all, but to store the status and category values in the original tables. You can accomplish this with an enumerable (ENUM) in MySQL or in Rails. In MySQL an ENUM is stored in the database as an integer, but it resolves to a word value, like 'processed', 'shipped' or 'canceled'. The benefit to this is that if your statuses do not change often you have one less join to do and it's easier to read the database and Ruby model. In Ruby an ENUM can simply be a list of constants that have a key (integer) and a value (string) associated with them. You can use the integer value to query and update the database and the word value on your application side.</p> <p>I believe both approaches are legitimate, the path you take really depends on your needs. If you are set on storing the data in the database, then analyze how you will be interacting with statuses and categories - your approach may be different. Which approach will be faster and easier to query? Which one will be easier to update or modify? How often do you read; how often do you write? Finally, keep in mind that you are Agile! Either approach can be transformed into the other with a simple migration and some refactoring. The approach that is simplest for your application now may not be the best one to use in the future, and that's perfectly okay. That's what's so great about being Agile!</p>
    singulars
    1. This table or related slice is empty.
    1. POWhat is a better way to set up a database for an app? Normalized vs real world
      singulars
      1. PTQuestion
    1. PTAnswer
    1. This table or related slice is empty.
    1. USPan Thomakos
    plurals
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. VO
      singulars
      1. PO
      1. This table or related slice is empty.
      1. VTUpMod
    2. VO
      singulars
      1. PO
      1. This table or related slice is empty.
      1. VTUpMod
    3. VO
      singulars
      1. PO
      1. This table or related slice is empty.
      1. VTUpMod
    1. COwell commented and explained...
      singulars
      1. PO
      1. USDRapp
    2. COThank you Pan, for a well explained answer. To your first point - I have tables - category_types & status_types, which hold the indicators for status & category. The ENUM approcah - won't work for me - cause statuses keep cahnging all the time: open, proccessed, active, discontinued, etc. Keep in mind that's it's a huge warehouse. Also to your point about extra attributes, such as effective data, can't I use table inheritance: For instance create a model OrderStatus < Status ?
      singulars
      1. PO
      1. USkonung
    3. COYes you can, that's definitely a viable option. It just means you have another table to join to which can be slower and more complex. It's okay if statuses change a lot for ENUMs. ENUMs don't work well when the universe of available statuses that can be assigned to an order change often.
      singulars
      1. PO
      1. USPan Thomakos
 

Querying!

 
Guidance
A row detail

Detail views are divided into sections. All the information in the data section comes from columns in the selected row. The other sections display data from other, related rows.

Related data can be related in a to-one or a to-many fashion. Captions of data related in a to-many fashion link to a list view showing a filtered view of the table.

Try moving around until you find a non-empty to-many entry and click on the label to get to one. You can move back to the root by clicking on the database name in the header.

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload