Does a date meet the requirements for choosing a primary key? - Unique - Irreducible (i.e. no part of the candidate key also qualifies as a primary key) - St

Does a date meet the requirements for choosing a primary key? - Unique - Irreducible (i.e. no part of the candidate key also qualifies as a primary key) - Stable (does not change over time) - Simple (a built-in type of the database engine qualifies) So, yes, a date meets the requirements. In a properly normalized schema all of the attributes (fields, columns) in the relation (row) depend on the primary key. You describe a table for a newsletter published no more than once per day. In that case the date makes a good primary key. Note that a date value for primary key is logically equivalent to an auto-incrementing integer surrogate key, assuming uniqueness holds (one newsletter per day). The advantage of the date is that it means something, whereas a surrogate key has no meaning, it exists only to satisfy the uniqueness requirement (and often indicates something went wrong when normalizing the schema). If you might ever post revisions on the same day and want to indicate that you would have to add that information to the primary key, e.g. (published-on DATE, revision INT) to maintain uniqueness. Date, date/time, and timestamp attributes either implicitly or explicitly refer to a specific timezone. That may or may not matter in your case (I suspect it doesn't), but timezone conversions and confusion give one reason a date or date/time value may not make a good key.