What is the better database table structure for storing a single row of data in MySQL?

Question

So I'm not sure exactly how to title this question. I am creating a database and need to store some default SEO info as follows.

default page title
default keywords
default page description
header code
footer code

There will never be more than 1 entry per field. So the question is do I create a table in the database with columns for each of these data types with the understanding that there will only ever be 1 row of data?

OR do I create a table that has a name column for each of the fields and then a column for the data (text)? With this option I can see that I wont be able to set the data type for each field, instead each would have to be tinytext or varchar.

Here are the 2 database table structures I'm contemplating.

CREATE TABLE `cms_seo` (
`id` int(2) NOT NULL,
`name` VARCHAR(100) NOT NULL,
`data` tinytext NOT NULL,
PRIMARY KEY (`id`)
)
INSERT INTO `cms_seo`
(`id`, `name`, `data`)
VALUES
(1, 'Website Keywords', ''),
(2, 'Default Page Title', ''),
(3, 'Default Page Description', ''),
(4, 'Header Code', ''),
(5, 'Footer Code', '');

OR

CREATE TABLE `cms_seo`(
`id` INT(1) NOT NULL AUTO_INCREMENT,
`default_page_title` VARCHAR(500) NOT NULL,
`default_keywords` VARCHAR(1000) NOT NULL,
`default_page_description` TINYTEXT NOT NULL,
`header_code` TINYTEXT NOT NULL,
`footer_code` TINYTEXT NOT NULL,
PRIMARY KEY (`id`)
)
INSERT INTO `cms_seo`
(`id`,
`default_page_title`,
`default_keywords`,
`default_page_description`,
`header_code`,
`footer_code`)
VALUES
(NULL, '', '', '', '', '');

Would there be any alternative to storing this data? Such as in a text file? The data will need to be editable through the cms.

Answer 1

It's a common pattern to store the type of data you describe in a "key/value" format like your design #1. Some advantages include:

• If your application needs a default for some new property, you can add it simply by INSERTing a new row.
• There's a practical limit to the width of a row in MySQL. But you can add as many rows as you want.
• If the list of defaults gets long, you can query for just one row. If you have an index, looking up a single row is more efficient.

Advantages of design #2:

• You can use MySQL data types to constrain the length or format of each column individually. Design #1 requires you to use a data type that can store any possible value.
• You store the property names as metadata, instead of as strings. Using metadata for property names is more "correct" relational database design.

I have posted many times in the past discouraging people to use the "key/value" design for data. But it's a legitimate use of that design when you just have one set of values, like the defaults in your case.

---

Another option, as you have mentioned, would be to store the data in file, instead of a database. See http://php.net/manual/en/function.parse-ini-file.php

Another option is to store the default values in a PHP file Just declare a hash array of them. One advantage of this technique is that a PHP file is converted to bytecode by PHP and then cached.

But since you say you have to be able to edit values through your application, you might find it easier to store it in a database.

Answer 2

This answer is really something in between a glorified comment and a full answer. I prefer option #2, because at some point in the future perhaps you might have the need for more than just one placeholder record. In addition, if you go with the second option you can make use of MySQL's relational capabilities, such as joining by column name.

Answer 3

There's nothing wrong with a table with only one row. (Relationally, its only candidate key is {}, but SQL doesn't let you express that directly.)

Relationally, ie if you want to ask arbitrary questions about individual keywords or collections of keywords, then you should store, query & manipulate this "row" as two tables:

CREATE TABLE `cms_seo`(
`id` INT(1) NOT NULL AUTO_INCREMENT,
`default_page_title` VARCHAR(500) NOT NULL,
`default_page_description` TINYTEXT NOT NULL,
`header_code` TINYTEXT NOT NULL,
`footer_code` TINYTEXT NOT NULL,
PRIMARY KEY (`id`)
)
CREATE TABLE `cms_seo_keyword`(
`seo_id` INT(1) NOT NULL,
`default_keywords` VARCHAR(1000) NOT NULL,
PRIMARY KEY (`seo_id`, `default_keywords`),
FOREIGN KEY (`seo_id`) REFERENCES `cms_seo` (`seo_id`)
)

You can declare a view for cms_seo in terms of these. Ideally you would program as much as possible using this database.

PS Design 1 is an EAV design. Reasearch EAV's problems. Essentially, it means you are using a DBMS to implement & use a (bug-filled feature-poor) program whose desired functionality is... a DBMS. You should only use such a design if you demonstrate that a straightforward relational design using DML & DDL gives insufficient performance but an EAV design does. (And that includes the present value/expense of EAV disadvantages.)