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

[Adelf]

Вторгнусь таки в дискуссию.

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

Ну давай-ка не смеши. С кешером оппкода реализация с массивом(если он не сильно большой конечно. страны - это максимум 200 записей) будет гораздо более быстрой. Быстрее даже чем мемкеш и уж точно быстрее базы.

Пример со странами плохой. Есть такой словарь. Пол человека. Женский, мужской. Иногда еще есть значение "не определено". Вы где значения храните? Тоже в базе?

 

[c0dex]

Adelf
а ну ка давай не смеши, где тут про кеш писали?

 

[c0dex]

То есть данные юзеров все ты тоже, как и автор, заносишь в массив, вместо базы, и там пишешь им какой пол?)

 

[Adelf]

c0dex
Данные юзеров хранятся в базе. Мне интересно, есть ли у вас таблица "sex" для хранения там данных этого словаря?

 

[Духовность™]

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

 

[c0dex]

Какая к чертям таблица sex?)))

 

[Adelf]

Я задал простой вопрос. "Есть ли у вас таблица "sex" для хранения там данных этого словаря?" special for c0dex - http://lingvo.yandex.ru/sex/с английского/ - используй 1) значение

Причины, которые побуждают хранение таких данных в коде не такие уж поверхностные. Не в производительности дело. Дело в том, что такие данные обладают влиянием на бизнес-логику. Т.е. в коде они в любом случае будут. Мужской или женский пол влияет на род глаголов и прилагательных используемых для данного юзера. Т.е. в коде уже присутствует знание о том, что пол бывает мужской и женский. В данном случае хранить это знание в бд - бессмысленно. Невозможно будет сделать так, чтобы добавить какое-либо значение в данную таблицу(да хрен с ним введем средний род приколу ради) и сайт спокойно начал работать без изменения кода. Точно также наверняка со статусами заказов в инет-магазинах. Это тоже словарь. Но он не обычно хранится отдельно в базе. Ибо нет смысла.
Я сознательно поменял словарь стран на пол, чтобы было удобно рассмотреть проблему. По вопросу автора - его уже разобрали. Любое изменение системы гораздо лучше будет перенесено если данные будут в базе. Отдельная логика в коде для отдельных значений стран - некрасиво. Поэтому и смысла хранить в коде мало.

 

[AmdY]

словарь может быть одной таблицей
id, dictonary, lang, key, value, deleted

 

[c0dex]

Adelf
Я довольно свободно владею английским, словарь оставь себе.

Мой вопрос был о том, на кой хрен свойство сущности выносить в отельную таблицу?

 

[Adelf]

c0dex
страна - это такое же свойство сущности.

 

[skwee]

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

Да юзер не обязан знать, я и не говорил что обязан, для этого есть Зенд

<select>
<?php foreach($counryCodes as $cc): ?>
  <option value="<?=$cc ?>"><?=Zend_Locale::getTranslation($cc, 'territorytocountry')?></option>
<?php endforeach; ?>
</select>

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

А я что должен предусматреть все возможные изменения стран в мире?
Если ты пишешь сайт для сравнения цен, ты же не будешь каждые 5 секуд получать курсы обмен всех валют, ибо тебе ни так важно если цена 10$ в рублях будет 300.51 или 300.59. А вот если ты пишешь платформу для торговли на бирже то да.

Adelf
а ну ка давай не смеши, где тут про кеш писали?

Вопрос задавался с уклоном на самое оптимальное решение. Можно все эти страны в xml запихать и парсить этот xml каждый запрос.

 

[Ragazzo]

Adelf
что-то я не понял, разъясни пожалуйста, т.е. при создании новых записей, ты кладешь атрибут sex не в БД, а пихаешь в noSQL хранилище чтоли всегда?или потом при выборке из БД ставишь это значение в какой-либо мемкеш?м?

 

[c0dex]

Блин, походу я вообще не улавливаю о чем ты хочешь написать.
Я предложил автору простой и расширяемый способ хранения данных. Можно расставить ссылки на страну по ее ключу и т.д.

Да, можно задефайнив, скажем, sex[male]=1, sex[female]=2, sex[undefined]=0, писать потом эти 0-1-2 в поля БД, только зачем?

 

[Adelf]

Ragazzo
Значение атрибута - конечно в бд. Я имею ввиду - где хранится сам словарь полов. Мужской, женский и какой-нибудь undefined. Это такой же словарь, как и страны. С такими же правами. Но, насколько я знаю, никто не выделяет отдельно таблицу для хранения его. Он обычно "хранится" тупо в коде.

c0dex
Вообще в данном случае(имея ввиду случай ТС) я сам за хранения в базе. Я просто немного критиканул ваши аргументы против хранения данных в коде. Хранят их там. Даже не замечая.

 

[skwee]

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

Я не говорил что у меня отдельная логика для каждой страны. Я всеголиш спросил, когда я делаю так

$user = new User();
$user->setCountry(new CountryCode('ZZ'));

Откуда класс countrycode должен знать что ZZ не валидный код страны? Где хранится его словарь? И в чем приемучество хранения этого словаря в бд если:
1. он не меняется, НИ КОГДА
2. мне не надо делать по ниму поиcк (например select CountrCode from Countries where CountryCode like 'R%')
3. мне не надо делать джоин с городами\поселками\регионами или хз что там еше.
4. мне надо иметь быстрый доступ как к валидации по коду (in_array($cc, $countryCodes)) так и для вывода <select> всех стран (пр. пост №31)

 

[Ragazzo]

Adelf
Понятно, ну если не привлекать NoSQL хранилища, я думаю если покопаться в паре ЦМС, можно найти схожие ситуации, где данные хранятся в БД все таки, все конечно зависит от конкретного случая.

 

[Adelf]

skwee
у тебя может такое произойти, что что-нибудь понадобится. В данном случае решение с базой даст тебе большую гибкость. А в производительности ты много не выиграешь скорее всего. В любом случае - 26*26 = 676 значений в memcache позволят тебе заменить in_array на очень быстрый(ну может чуток медленней) аналог.

 

[Ragazzo]

skwee
ну пихни ты уже его в private свойство вида

countryCodes = array(
 'Ru'=>'ru'
);

или как там у тебя и все. проблема вообще надуманная, и исходит из того "а что будет если я сделаю неправильно вот эту мелкую вещь", если что исправишь за 5 минут, не такая уж это и проблема.

 

[skwee]

skwee
В любом случае - 26*26 = 676 значений в memcache позволят тебе заменить in_array на очень быстрый(ну может чуток медленней) аналог.

вот именно, memcache, значит храним в базе, потом все это дело надо проводить через memcahce...

skwee
ну пихни ты уже его в private свойство вида
или как там у тебя и все. проблема вообще надуманная, и исходит из того "а что будет если я сделаю неправильно вот эту мелкую вещь", если что исправишь за 5 минут, не такая уж это и проблема.

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

Все топик клосед, спасибо всем))

 

[stopkran]

4. мне надо иметь быстрый доступ как к валидации по коду (in_array($cc, $countryCodes)) так и для вывода <select> всех стран (пр. пост №31)

Как валидацию, так и генерацию select лучше делать на стороне клиента. Отсюда вытекает словарь в файле .js (который принципиально быстрее БД, мемкэша, php и вообще чего угодно на стороне сервера).