Inheritance & PolymorphismIn Relational Databases
Upcoming SlideShare
Loading in...5
×
 

Inheritance & Polymorphism In Relational Databases

on

  • 4,932 views

 

Statistics

Views

Total Views
4,932
Views on SlideShare
4,923
Embed Views
9

Actions

Likes
2
Downloads
45
Comments
1

1 Embed 9

http://www.slideshare.net 9

Accessibility

Upload Details

Uploaded via as Microsoft PowerPoint

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
  • Very nice explanation. If you are interested: review of each implementation (another problem is described) you can find here: http://www.vertabelo.com/blog/inheritance-in-a-relational-database
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

Inheritance & PolymorphismIn Relational Databases Inheritance & Polymorphism In Relational Databases Presentation Transcript

  • Inheritance & Polymorphism In Relational Databases solving some common problems in web development
  • The Problem
    • Books & Televisions
    • Both
      • SKU
      • Title
      • Description
      • Manufacturer
    • Books
      • ISBN
      • Author
    • Televisions:
      • Screen Size
      • Resolution
  • Own Tables
    • Duplication of shared fields
      • Gets worse with more products
    • Lose indexing of shared fields
      • i.e. SKU unique across products
    SELECT * FROM books WHERE id = 7 SELECT id, title, ‘book’ AS type FROM books UNION SELECT id, title, ‘television’ AS type FROM televisions
  • Single table inheritance (STI)
    • No duplication
    • Wasted fields
      • Gets worse with more products
    • Rails built in inheritance
    SELECT * FROM products WHERE id = 7 SELECT id, title, type FROM products
  • Class Table Inheritance (CTI)
    • No duplication
    • No wasted fields
    • Index shared fields
    • Referential integrity
    • Difficult to enforce books or televisions
    • Creating and reading becomes more complex
    SELECT books.*, products.* FROM books JOIN products ON(products.id = books.product_id) WHERE books.id = 7 SELECT products.id, products.title, books.id, televisions.id FROM products LEFT JOIN books ON(books.product_id = products.id) LEFT JOIN televisions ON(televisions.product_id = products.id)
  • Another Problem
    • Tags for Books and Televisions
    • Reference Products from Tags
    • What about tagging other things besides Products as well?...
  • Multiple Tables
    • Duplication of Tag structure
    • Need new table for each thing
    • Can’t index across all tags
  • Multiple Relationships
    • Single Tag structure
    • Can index all Tags
    • Need similar tables for anything we want to tag
    • Need some app logic
      • Deleting Product deletes relationship, not Tags themselves
  • Class Table Inheritance
    • Generalize Products and Images
    • Avoids duplication
    • Alter existing structures
    • Increasing complexity
      • Books span 3 tables
    • Tightly coupled
      • Adding Comments: “TaggableCommentables”?
  • Polymorphism
    • Simple
      • Just one Tags table to Tag anything
    • No changes to existing entities
    • Can handle tagging of any future entities
    • Loses referential integrity
      • Need to enforce in application logic
    • Comments could be added similarly
    • Rails has it built in