OK, I think you need to break this out into the basic “varieties”. You have two “entity”-style objects: User Campaign You have one “mapping”-style object: UserCampaign You have one “transactional”-style object: Click Step 1: entity Let’s start with the easy ones: User & Campaign. These are truly two separate objects, neither one really depends on … Read more
I’m no couchdb expert, but after having done a little research this is what I’ve found. The simple answer is, use UUIDs unless you have a good reason not to. The longer answer is, it depends on: Cost of changing ID Vs How likely the ID is to change Low cost of changing and likely … Read more
This is the table structure i came up with; Schedule – ScheduleName – ScheduleTypeId (Daily, Weekly, Monthly, Yearly, Specific) – StartDate – IntervalInDays – Frequency – FrequencyCounter ScheduleDaily – ScheduleDailyId – ScheduleId – TimeOfDay – StartDate – EndDate ScheduleMonthly – ScheduleMonthlyId – ScheduleId – DayOfMonth – StartDate – EndDate ScheduleSpecific – ScheduleSpecificId – ScheduleId – … Read more
I don’t think there is a blanket statement that you should only ever use a single primary key named id. Most people use a surrogate primary key as an auto generate int, because it isolates the primary key from ever needing to be changed, like if you make the PK the user name and they … Read more
If it is for SQL Server I like the DB Diagram from SQL Server Management Studio.
There is a catch in what you ask for: it all depends on your data. Fundamentally Redis is a data structure server. How you structure your data depends almost entirely on what it is and how you need to access it. The simple and common cases are fairly well covered by the links you list. … Read more
It all depends on data volumes and content to tag distribution and density ratios If you have a low tag distribution and density ratio (typical human generated data) you can simply generate an unique id or hash for each possible collection of tags in use by the data. Associate the ‘tag collection’ id with each … Read more
Article { “_id” : “A”, “title” : “Hello World”, “user_id” : 12345, “text” : ‘My test article’, “comments” : [ { ‘text’ : ‘blah’, ‘user_id’ : 654321, ‘votes’ : [987654]}, { ‘text’ : ‘foo’, ‘user_id’ : 987654, ‘votes’ : [12345, 654321] }, … ] } The basic premise here is that I’ve nested the Comments … Read more
Here’s one way to implement supertype/subtype tables for your app. First, the supertype table. It contains all the columns common to all subtypes. CREATE TABLE publications ( pub_id INTEGER NOT NULL PRIMARY KEY, pub_type CHAR(1) CHECK (pub_type IN (‘A’, ‘B’, ‘P’, ‘S’)), pub_url VARCHAR(64) NOT NULL UNIQUE, CONSTRAINT publications_superkey UNIQUE (pub_id, pub_type) ); Next, a … Read more
How about the Materialized Path design? CREATE TABLE trie ( path VARCHAR(<maxdepth>) PRIMARY KEY, …other attributes of a tree node… ); To store a word like “stackoverflow”: INSERT INTO trie (path) VALUES (‘s’), (‘st’), (‘sta’), (‘stac’), (‘stack’), (‘stacko’), (‘stackov’), (‘stackove’), (‘stackover’), (‘stackover’), (‘stackoverf’), (‘stackoverflo’), (‘stackoverflow’); The materialized path in the tree is the prefixed sequence … Read more