Где храним константную статику?

skwee

Новичок
Добрый вечер!
Хочу обсудить где и как лучше всего хранить константные данные?
Пример: массив всех стран в мире. В бд хранить тупо ибо это данные нужны при каждом запросе да и меняется они вроде не будут.

Сделать статик массив в модели Country?
чтото вроде
PHP:
class Country extends ValueObject {
  private static $Countries = array(
  //очеень длинный массив
  );

  private $_code;

  public function __construct($code) {
    if(!array_key_exists($code, self::$Countries)) throw new InvalidValueObjectException(...);
    $this->_code = $code;
  }

  public function getCode() { return $this->_code; }

  public function getName() { return self::$Countries[$this->_code]; }

  ...
}
 

c0dex

web.dev 2002-...
Команда форума
Партнер клуба
а потом добавить туда страну, или сделать вывод поиск типа LIKE %% и зае...ться...
 

AmdY

Пью пиво
Команда форума
skwee
создай класс словарь, в конструктор передаётся имя конкретного словаря, геттер в который передаётся ключ в этом словаре и геттер с поиском по фильтрам, как писал c0dex. Хранить словари лучше в базе, так проще редактировать, можно организовать кеширование, рулетку, блэкджек и что там положено.
 

skwee

Новичок
c0dex а у нас что каждый день новая страна?

AmdY Иртерестный подход со словарем, спасибо!

Духовность™ Почему? Это же статика, которая не меняется.
 

c0dex

web.dev 2002-...
Команда форума
Партнер клуба
skwee
У вас не знаю, у меня куча вариантов развития событий, и толку в таком коде, что ты привел - ноль.
 

AmdY

Пью пиво
Команда форума
ах, у словарей может быть ещё язык, это нужно учитывать
 

skwee

Новичок
Духовность™ статья как сущность меняется. Сейчас у меня нет ни одной статьи, а завтра их будет 10. Хранилище сущности "статья" поменялась, поэтому она не статичная и не константная. А вот страны да, они не меняются на ежедневной базе, это константная статика, так же как языки или алфавит.
Я не ищу по стране, на много правильнее делать так
PHP:
public function getUsersFrom($ccode) {
  return $this->getDao()->query('SELECT * FROM users WHERE CountryCode = ?', $ccode);
}
====
$users = $userRepository->getUsersFrom('RU');
Мне в голову не приходит не одной мысли где мне надо будет делать LIKE %% на имя страны. Кроме например ajax формы которая автозополняет страну юзера когда он пишет ее, но и там будет select * from Countries и потом кеш и фильтрация на стороне пхп, не делать же мне селект лайк на каждый символ который юзер написал.
А например http хедеры с кодамы ты бы тоже в бд хранил?

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

Духовность™

Продвинутый новичок
А например http хедеры с кодамы ты бы тоже в бд хранил?
"http хедеры с кодамы" - это шаблон, это часть программы. Страны и города - это словари. Это данные, которые нужно хранить в бд.
Если ты ещё не понял поченму, то я объясню. Во первых, нормальные базы стран и городов могут иметь ссылку на родительский регион или ссылку на регион-потомок.
Например, Россия-Московская Область-Москва. Для хранения таких данных уже нужна БД.
Далее, когда-то буждет задача выбирать все эти данные, делать JOIN-запросы. Как пример - выбрать пользователей и место их проживания.
Твой статичный массив проклянут разработчики и забьют все данные в базу.

И да. Выборка 300 записей из базы - копеечная операция даже без кэширования.
 

skwee

Новичок
Принято называть Enumeration, под ValueObject обычно понимают кое-что другое.
Color это ValueObject, а "red", "green", "blue", "0xFF00FF" это возможные его значения. Или еще проще Integer это тоже VO а 7, 10, -25 это значения. Возможно правильнее было назвать не Country а CountryCode, и тогда в данном контексте, RU, US и тд, это возможные значения для CountryCode. Я не прав?

"http хедеры с кодамы" - это шаблон, это часть программы. Страны и города - это словари. Это данные, которые нужно хранить в бд.
Если ты ещё не понял поченму, то я объясню. Во первых, нормальные базы стран и городов могут иметь ссылку на родительский регион или ссылку на регион-потомок.
Например, Россия-Московская Область-Москва. Для хранения таких данных уже нужна БД.
Далее, когда-то буждет задача выбирать все эти данные, делать JOIN-запросы. Как пример - выбрать пользователей и место их проживания.
Твой статичный массив проклянут разработчики и забьют все данные в базу.

И да. Выборка 300 записей из базы - копеечная операция даже без кэширования.
Ну да с хедерами пример плохой.
Почему в БД? у тебя логика "раз словарь значит в БД" и я ее не понимаю.
Для простоты задачи добавлю что меня не интересует (на данный момент) города и регионы, мне просто надо знать с какой страны пользователь а вывести ему
PHP:
echo _('Welcome back'), ' ', $user->getName(), ' ', _('from'), ' ', $user->getCountryName();
 

c0dex

web.dev 2002-...
Команда форума
Партнер клуба
Тебе же сказали, как люди делают, ты хотел обсудить, но видимо ты пришел поупираться и постоять на своем. Делай как хочешь.
 

Вурдалак

Продвинутый новичок
Color это ValueObject, а "red", "green", "blue", "0xFF00FF" это возможные его значения. Или еще проще Integer это тоже VO а 7, 10, -25 это значения. Возможно правильнее было назвать не Country а CountryCode, и тогда в данном контексте, RU, US и тд, это возможные значения для CountryCode. Я не прав?
Принято называть Enumeration, под ValueObject обычно понимают кое-что другое.
 

skwee

Новичок
Тебе же сказали, как люди делают, ты хотел обсудить, но видимо ты пришел поупираться и постоять на своем. Делай как хочешь.
Нет мне не сказали (крому AmdY), а аргумент вроде "страны это словарь поэтому храни в БД" это не аргумент. Я поставил задачу (пост №1 и №14) а мне говорят "ну а если искать по лайк или по городу\региону". У меня этого нету, у меня есть массив ИЗО кодов стран, юзер выбирает себе страну проживания. В чем преимущество хранит эти коды в БД а не в xml/csv/php array? И да для твоего аргумента "а если добавит страну", у меня страны не меняются, пусть даже ядерная война, у меня их как было X так и останится X. А тепер приведи пожалуйста свой аргумент за БД (если еше осталось желание).

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

Духовность™

Продвинутый новичок
а аргумент вроде "страны это словарь поэтому храни в БД" это не аргумент
Я тебе привел аргумент - любые данные, которые ВОЗМОЖНО придется джойнить нужно хранить в БД. Это хороший тон разработки.

Для простоты задачи добавлю что меня не интересует (на данный момент) города и регионы, мне просто надо знать с какой страны пользователь а вывести ему
ну выведи. в чем проблема тогда?
 

skwee

Новичок
Я тебе привел аргумент - любые данные, которые ВОЗМОЖНО придется джойнить нужно хранить в БД. Это хороший тон разработки.
да я не спорю, токо вот я ни где не говорил что мне ВОЗМОЖНО придется их джойнить. Я тебе даже больше скажу их ТОЧНО не придется джойнить. Это всего лиш ИЗО код.

ну выведи. в чем проблема тогда?
Понимешь, ИЗО код страны это две буквы, у каждой страны они уникальны и ни когда не будет двух стран с кодом RU.
PHP:
$user = new User();
$user->setCountry(new CountryCode('ZZ'));
ZZ не валидный код, как мне это занть? По словарю валидных кодов. А вопрос как его хранит? И да добавлю цитату из поста №17
у меня страны не меняются, пусть даже ядерная война, у меня их как было X так и останится X
 

c0dex

web.dev 2002-...
Команда форума
Партнер клуба
Ну аргумет хотя бы в том, что выбрать одну страну с БД, это тебе не дергать на каждый "пук" весь твой массив. А это именно так и будет при инклюде файла. Юзер не обязан знать какие там у тебя коды, он хочет выбрать родную Россию, или там Зимбабве какую, и что в итоге?

у меня страны не меняются, пусть даже ядерная война
Это мало кого волнует, что у тебя там не меняется, налицо сейчас проблема расширяемости, с тем же поиском, линковкой городов к тем же странам, и еще кучей дополнительных возможных путей развития. ИХ НАДО учитывать. А не искать копеечную выгоду, как тебе кажется, от того, что ты заюзал Array хранилище, вместо БД (NoSQL).
 
Сверху