2. • Plan your db
• What information must be stored?
• In which tables
• In what form?
3. • Goal of db design
• Minimum redundancy
• Integrity (Relational and data)
• Performance
4. • Normalization!
• minimizes redundancy
• no anomalies
• update - same data in two places
• delete - only one record
• insert - inserting one attribute requires inserting
additional info.
• HTML and browser as a thin client
• Page based architecture
• Distribution problem solved!
7. • Joins
• inner join - only when there is a match
• left join - all from first table even if there are no
matches in second table
• right join - all from 2nd table even if there are no
matches in first table
• outer join - An OUTER JOIN retrieves data from both
tables, when there are no matching values in the
tables.The end result will be a summation of all rows
in both tables.
8. • Example
SELECT * FROM product_prd INNER JOIN
category_ctg ON product_prd.idctg_prd =
category_ctg.id_ctg
9. • Best practices
• Comment
• don’t store binary data
• same column in diff. tables should have same
datatype (ex: foreign key)
• no select *
• when running an insert action query, use the
columns list into which to insert instead of the
table name
10. • Why naming convention
• Clear structure
• Everyone is on same page
• Maintenance
12. • prefix the db name with the name of environment - proto_DB live_DB etc.,
• Table names
• name of entity
• prefix tables that are related ex: user_decisions, user_results
• no generic prefixes
• singular for table names
13. • columns
• use id for primary keys. user_id,
• foreign key should have id, cat_prod_id (refers to categories table, belongs to
products and is not a key)
• each column should be followed by a 3 letter table acronym. name_prd, name_cat
14. • Security
• SQL Injection - more here
SELECT fieldlist
FROM table
WHERE field = ‘'anything' OR 1=1’;