Как хранить наборы статических данных (справочники) PHP или БД?

Question

[stfed]

Коллеги, доброго дня всем!

Работаю со связками PHP + MySQL
В проектах всегда присутствуют наборы статических данных т.н. справочники.
Т.е. это данные которые заранее определены и практически никогда не меняют в процессе жизни проекта.
К примеру единицы измерения: 'м', 'шт', 'кг', 'л' ....
Или список должностей: 'Менеджер', 'Директор', 'Заместитель директора', 'Бухгалтер', 'Логист', 'Водитель' ...
На этапе разработки удобно использовать простые массивы

$unit_list = array('м', 'шт', 'кг', 'л');
$worker_post = array('Менеджер', 'Директор', 'Заместитель директора', 'Бухгалтер', 'Логист', 'Водитель', 'Начальник склада', 'Кладовщик', 'Оператор БД');

И хранить их в отдельном файле
Со временем таких справочников становится, мягко говоря, много.
Так же, редко, но иногда приходится вносить какие-то правки. К примеру добавить новую должность.
Имеет ли смысл выносить такие справочники в формат БД?
Каким образов вы организуете работу с такими статическими данными?

ПС: массивы таких данных могут быть двухмерными...

Answer 1

[Армянское Радио]

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

Comments

[stfed]

Спасибо за совет. Можно подробнее как у вас это работает? Вы храните справочники в одной таблице? Или все в разных?

[Армянское Радио]

stfed: Каждому справочнику - своя таблица. Иначе будет бардак.

Answer 2

[FanatPHP]

По опыту, ситуация, когда добавление значения в словарь требует отдельного коммита в репозиторий и плюс, возможно, внеочередной выкатки - не говоря уже о том, что добавление делается программистом, а не редактором - со временем начинает бесить.

Проще свести все словари в одну иерархию, написать 1 раз для нее админку и забыть.

Про "никогда не меняются" - это фантазия.

Comments

[stfed]

Да, я хоть и написал, что "никогда не меняются" - но ниже оговорился "редко, но иногда приходится"

Делать под каждый справочник свою таблицу, мне кажется не стоит...
В процессе разработки встает вопрос о создании новых справочников.

Думаю обойтись двумя таблицами:
1. Список справочников: ед. измерений, цвета, должности, статусы...
2. Непосредственно сами данные справочников: шт, м, л, кг (ссылаются на ИД из первой таблицы)

Как быть с двухмерными массивами?
К примеру: типы файлов МОфиса
$mso = array(
array('word', 'application/vnd.ms-word.document.macroEnabled.12'),
array('word', 'application/vnd.ms-word.template.macroEnabled.12'),
array('excel', 'application/vnd.ms-excel'),
array('excel', 'application/vnd.ms-excel'),
....
);

[FanatPHP]

ну, в древовидную таблицу можно впихнуть вообще все...

[stfed]

Конкретнее можете на примере выше...

Answer 3

[Alzasr]

Я организую каждый справочник как класс и там инкапсулирую метод хранения данных. На этапе разработки можно хранить массивом PHP, но в продакшене в большинстве случаев использую БД, а так как метод хранения инкапсулирован в класс, то переход от массива к БД безболезненен.

//Dev version
class ExampleDict{
    private static $_array = array(1=>'value1',2=>'value2');
    public static function getValues(){
        return self::$_array;
    }
}

//Prod version
class ExampleDict{
    private static $_array;
    public static function getValues(){
        if(empty(self::$_array)){
            self::reloadValues();
        }
        return self::$_array;
    }
   
    public static function reloadValues(){
         self::$_array = app::db->queryAssoc('select `id`,`value` from `dict`','id','value');
    }

}

Метод app::db->queryAssoc('select `id`,`value` from `dict`','id','value) - взят от балды, не знаю чем ты пользуешься, должен возвращать ассоциативный массив 'id'=>'value'
Ну и это один из вариантов, примитивный, написан из головы, через статические методы. В Yii я пользуюсь моделями ActiveRecord, там работа не со статическими методами

Comments

[stfed]

Можете сюда кусок кода для примера?

[Alzasr]

stfed: ответ отредактировал.

Answer 4

[stfed]

Как вариант такая схема:
Таблица dataset_list - содержит список наборов данных, где
- caption это название "Единицы измерения"
- alias это псевдоним "unit_list"

CREATE TABLE `dataset_list` (
  `id` int(11) NOT NULL AUTO_INCREMENT,
  `caption` varchar(255) NOT NULL DEFAULT '',
  `alias` varchar(255) NOT NULL DEFAULT '',
  `active` enum('1','0') NOT NULL DEFAULT '1',
  PRIMARY KEY (`id`)
) ENGINE=MyISAM DEFAULT CHARSET=cp1251;

Таблица dataset_item содержит сами наборы данных
- catalog_id ссылка на таблицу dataset_list (к какому списку относится данная позиция)
- key это псевдо ключ как в массиве
-captionA-Е - это поля данных, несколько полей для "многомерности"

CREATE TABLE `dataset_item` (
  `id` int(11) NOT NULL AUTO_INCREMENT,
  `catalog_id` int(11) NOT NULL DEFAULT '0',
  `key` int(11) NOT NULL DEFAULT '0',
  `captionA` varchar(255) NOT NULL DEFAULT '',
  `captionB` varchar(255) NOT NULL DEFAULT '',
  `captionC` varchar(255) NOT NULL DEFAULT '',
  `captionD` varchar(255) NOT NULL DEFAULT '',
  `captionE` varchar(255) NOT NULL DEFAULT '',
  `active` enum('1','0') NOT NULL DEFAULT '1',
  PRIMARY KEY (`id`),
  KEY `catalog_id` (`catalog_id`),
) ENGINE=MyISAM DEFAULT CHARSET=cp1251;

Comments

[FanatPHP]

не надо так уж совсем говнокодить. captionA-Е - это гребаный стыд

[stfed]

FanatPHP: Самому не нравится... Варианты какие? Мы заранее не можем какие данные лягут в эти поля

[65536]

stfed: это не ебаный стыд это ебаный пиздец, добавляйте таблицу dataset_fields с полями id, field_name, мб еще units сюда если надо. еще таблицу dataset_items_fields_values с полями id, dataset_item_id, dataset_field_id, value. из dataset_list алиас и капшн ваще убрать, у вас же единицы изменерения принадлежат параметрам а не спискам параметров. и что еще за псевдонимы)))

еще хочу сказать. catalog_id ссылка на таблицу dataset_list - как вы через пол года собираетесь до этого догадаться? или другой программист, да он вас проклянет. тут либо поле должно называться dataset_list_id, либо таблица catalogs. да и в первом случает не dataset_list а dataset_lists

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