Какова лучшая структура таблицы базы данных для хранения одной строки данных в MySQL?

Обычно тип данных, который вы описываете, хранится в формате «ключ/значение», как в вашем проекте № 1. Некоторые преимущества включают в себя:

• Если вашему приложению требуется значение по умолчанию для какого-либо нового свойства, вы можете добавить его, просто вставив новую строку.
• В MySQL существует практическое ограничение ширины строки. Но вы можете добавить столько строк, сколько хотите.
• Если список значений по умолчанию становится длинным, вы можете запросить только одну строку. Если у вас есть индекс, поиск по одной строке более эффективен.

Преимущества конструкции №2:

• Вы можете использовать типы данных MySQL, чтобы ограничить длину или формат каждого столбца по отдельности. Схема № 1 требует, чтобы вы использовали тип данных, который может хранить любое возможное значение.
• Вы сохраняете имена свойств как метаданные, а не как строки. Использование метаданных для имен свойств является более «правильным» дизайном реляционной базы данных.

В прошлом я много раз писал, что отговариваю людей от использования схемы «ключ/значение» для данных. Но это законное использование этого дизайна, когда у вас есть только один набор значений, таких как значения по умолчанию в вашем случае.

Другой вариант, как вы упомянули, - хранить данные в файле, а не в базе данных. См. http://php.net/manual/en/function.parse-ini-file.php

Другой вариант - сохранить значения по умолчанию в файле PHP. Просто объявите их хэш-массив. Одним из преимуществ этого метода является то, что файл PHP преобразуется PHP в байт-код, а затем кэшируется.

Но поскольку вы говорите, что должны иметь возможность редактировать значения через свое приложение, вам может быть проще хранить их в базе данных.

Этот ответ действительно что-то среднее между прославленным комментарием и полным ответом. Я предпочитаю вариант № 2, потому что в какой-то момент в будущем вам может понадобиться более одной записи-заполнителя. Кроме того, если вы выберете второй вариант, вы сможете использовать реляционные возможности MySQL, такие как объединение по имени столбца.

Нет ничего плохого в таблице только с одной строкой. (Относительно, его единственный ключ-кандидат — {}, но SQL не позволяет вам выразить это напрямую.)

Реляционно, то есть если вы хотите задать произвольные вопросы об отдельных ключевых словах или наборах ключевых слов, вам следует хранить, запрашивать и манипулировать этой «строкой» как двумя таблицами:

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`)
)

Вы можете объявить представление для cms_seo с их точки зрения. В идеале вы должны программировать как можно больше, используя эту базу данных.

PS Design 1 — это дизайн EAV. Исследуйте проблемы EAV. По сути, это означает, что вы используете СУБД для реализации и использования программы (наполненной ошибками и бедной функциональностью), чья желаемая функциональность - это... СУБД. Вы должны использовать такой дизайн только в том случае, если вы демонстрируете, что простой реляционный дизайн с использованием DML и DDL дает недостаточную производительность, а дизайн EAV дает. (И это включает текущую стоимость / расходы на недостатки EAV.)