I would use a ‘link’ concept for all future recurring events. They are dynamically displayed in the calendar and link back to a single reference object. When events have taken place the link is broken and the event becomes a standalone instance. If you attempt to edit a recurring event then prompt to change all … Read more
Maybe a bit different approach — supertype/subtype is usually used when you have very specific columns for each subtype, like in Person supertype with Patient and Doctor subtypes. Person holds all data common to people and Patient and Doctor hold very specific columns for each one. In this example your book_notes and article_notes are not … Read more
The criteria for consideration of a primary key are: Uniqueness Irreducibility (no subset of the key uniquely identifies a row in the table) Simplicity (so that relational representation & manipulation can be simpler) Stability (should not be altered frequently) Familiarity (meaningful to the user)
Certain issues need to be clarified and resolved before we can enter into a reasonable discussion. Pre-requisite Resolution Labels In a profession that demands precision, it is important that we use precise labels, to avoid confusion, and so that we can communicate without having to use long-winded descriptions and qualifiers. What you have posted as … Read more
Survey Database Design Last Update: 5/3/2015 Diagram and SQL files now available at https://github.com/durrantm/survey If you use this (top) answer or any element, please add feedback on improvements !!! This is a real classic, done by thousands. They always seems ‘fairly simple’ to start with but to be good it’s actually pretty complex. To do … Read more
No matter how you structure your overall document there are basically two things you need. That is basically a property for a “count” and a “list” of those who have already posted their “like” in order to ensure there are no duplicates submitted. Here’s a basic structure: { “_id”: ObjectId(“54bb201aa3a0f26f885be2a3”) “photo”: “imagename.png”, “likeCount”: 0 “likes”: … Read more
I say it’s a bad idea, generally (with some exceptions, perhaps). First, your database should be backed up regularly, so you should never be in a situation where you would lose data permanently because of a DELETE (unless it’s a deletion of just-added data, of course). Second, a soft delete like this means you now … Read more
Martin Fowler discusses this extensively in his book Patterns of Enterprise Application Architecture book. Get this book and look into: Single Table Inheritance Class Table Inheritance Concrete Table Inheritance The Website should give you some idea. You might also want to read the section on inheritance mappers. Each of the different approaches have their pros … Read more
An identifying relationship is when the existence of a row in a child table depends on a row in a parent table. This may be confusing because it’s common practice these days to create a pseudokey for a child table, but not make the foreign key to the parent part of the child’s primary key. … Read more
Three tables (one for storing all items, one for all tags, and one for the relation between the two), properly indexed, with foreign keys set running on a proper database, should work well and scale properly. Table: Item Columns: ItemID, Title, Content Table: Tag Columns: TagID, Title Table: ItemTag Columns: ItemID, TagID