4 ms·

> IDs should get an _id suffix, and primary keys should be called $OBJECT_id (e.g., order_id, user_id, subscription_id, order_item_name_id). Wrong. Be consist

• benmanns 7y ago
  I don't know—this could be seen as more consistent. It's almost like a type system on identifiers. This way you avoid accidentally joining users.id to user_preferences.id because you'll always join with the user_id "type" from users.user_id to user_preferences.user_id. SQL even has a syntax for that: JOIN user_preferences USING (user_id).
• Ma8ee 7y ago
  No, clarity is much more important than consistency. And I much prefer to see an expression like O.order_id = CO.order_id than O.Id = CO.order_id
  • roland-s 7y ago
    If you're using table aliases like "O" you're already throwing clarity out the window. The following is perfectly clear and readable IMO: Orders.id = Customers.order_id and also indicates which column is the primary key and which is the foreign key. What about other column names duplicated across tables, should Orders.created_at = Customers.created_at become Orders.order_created_at = Customers.customer_created_at Scope exists for a reason, don't be afraid to use it!
    • Ma8ee 7y ago
      The reason we use aliases is it almost only in toy-examples that most tables are called things like Order. I won't fill my SELECT with row after row with CustomerOrderRowHistory... And your second example kind of prove my point. When it it written out like that it become obvious that you are trying to compare diffent quantities. There is clearly something wrong when you are trying to join on order_created_at = customer_created_at which isn't at all as clear with your way of writing.
• kbd 7y ago
  > All id's are named ID or id. From someone who's done a lot of data modeling, imo this is not good advice. I recommend naming your IDs "{table}_id". Then it's extremely clear what it refers to when it's used as a foreign key, and you can join naturally using SQL's 'using' statement as it's intended to be used.