Модель состояния MySQL - лучшая реализация? - PullRequest
0 голосов
/ 12 ноября 2009

Итак, я работаю над системой-фреймворком с одним из моих сотрудников. Наша текущая задача состоит в том, как наилучшим образом реализовать статусы. Часто статус будет содержать уникальные данные (цвет строки таблицы или текст, отображаемый пользователю и т. Д.). В настоящее время у нас есть таблица состояний, которая содержит все эти данные. В этой таблице содержится столбец: «css_class», который, когда у записи есть этот статус, указанный класс CSS присоединяется к элементу (в данном случае tr). Кроме того, чтобы присвоить другой записи определенный статус, в этой таблице базы данных указывается внешний ключ (в этом случае пользователь имеет определенный статус. Поэтому в таблице users есть внешний ключ statuses_id). Эта реализация работает нормально, но есть несколько проблем. Во-первых, что если мне нужно выполнить определенное действие в PHP, если запись находится в определенном состоянии? То, как мы делаем это сейчас, выглядит примерно так:

if($user->status==0) 
{
    //execute some code
}

Это действительно не работает, если статусы могут измениться. Измените одно состояние, и связанный код либо сломается, либо будет работать не так, как предполагалось.

Другая проблема и основная причина публикации вопроса состоит в том, что таблица содержит столбец "css_class". Это очень универсально и позволяет нам очень быстро менять стиль определенного статуса. Но нам действительно не нравится идея помещать код в базу данных. Возможно, наличие классов CSS в базе данных не обязательно плохо, но я действительно не знаю, какова общая практика. Есть идеи?

EDIT:

Что я понял из первых нескольких ответов, так это то, что я должен держать все свои представления в рамках модели, чтобы поддерживать инфраструктуру MVC. Мой аргумент заключается в том, что если я оставлю имя css_class вне базы данных, то я проверяю идентификатор статуса в представлении, чтобы решить, какой класс ему назначить. Поэтому, если я помещаю класс в базу данных, я помещаю информацию о просмотре в модель. Если я не помещаю CSS-классы в базу данных, я помещаю информацию о модели в представление (проверяя, к какому идентификатору она принадлежит). Так что, не запутав модель, я вместо этого запутал вид .......

Ответы [ 3 ]

2 голосов
/ 12 ноября 2009

Самый элегантный способ, который я видел до сих пор решенным (и я уже работал с несколькими реализациями MVC), заключается в хранении только соответствующих данных в базе данных. Например. Вы бы сохранили статус = «красный» в базе данных и оставили его на усмотрение, чтобы знать, что делать с красным статусом, с точки зрения CSS. Затем проблема решается путем разработки достаточно продвинутого слоя View, который создает многократно используемые структуры - таким образом, вам не нужно постоянно обновлять данные постранично при изменении CSS.

Передача этой информации в Модель несколько противоречит точке разделения контента / презентации, потому что теперь ваш код должен знать, чтобы извлечь информацию о презентации из базы данных и направить ее на уровень просмотра или, дрожь , вы извлечете этот материал из базы данных прямо в коде слоя View, что делает обслуживание кошмаром, поскольку вы теперь потеряли контроль над информационным потоком.

0 голосов
/ 12 ноября 2009

С точки зрения моделирования данных:

  • Иметь разные таблицы для каждого «вида» статуса; Держите пользовательские статусы отдельно от статусов страниц (например) - группируйте подобные объекты вместе.
  • Не помещайте CSS-классы в базу данных, но используйте некоторую форму индикатора состояния - это может быть столбец ENUM, если вы заранее знаете набор возможных состояний. Преобразуйте это в соответствующий класс CSS в слое представления. Вы не хотите оказаться в ситуации, когда ваш CSS не может быть изменен, потому что некоторые данные в базе данных мешают этому.
0 голосов
/ 12 ноября 2009

Если вы хотите продолжить свою парадигму хранения этого в БД, вы можете создать другую таблицу, которая отображает имена статусов VARCHAR и соответствующие им идентификаторы INTEGER.

Впрочем, если это были мои рамки. Я бы не стал хранить такую ​​информацию в базе данных. Это будет обработано V моей MVC настройки.

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