Небольшой вопрос по проектированию

[HraKK]

pilot911
Лучше иногда жевать дирол, ога?

 

[С.]

Предлагаю "срединный путь" -- мнемоника и экономия в одном флаконе. Тип поля CHAR(1), значения полей соответственно "P", "D", "H" и т.п.

 

[Kib]

Автор оригинала: С.
Предлагаю "срединный путь" -- мнемоника и экономия в одном флаконе. Тип поля CHAR(1), значения полей соответственно "P", "D", "H" и т.п.

Помоему это не чем не лучше чем int

 

[Nelius]

pilot911
Спасибо. Думал об этом, это хороший вариант когда есть фиксированный набор статусов и необходимость устанавливать для записи несколько статусов одновременно.

 

[HraKK]

Nelius
Для этого есть связь один ко многим.

 

[Nelius]

HraKK
Я знаю про эту связь.
Вопрос в том оптимально ли ее применять когда значение может быть только 1 и 0.
В примере который привел pilot911, я так понял, как раз только 1 или 0 подразумевалось.

Вопрос рассматривается с точки зрения максимальной производительности.
Основная цель, понять, где и когда следует отступать от "правильного" проектирования БД ради увеличения производительности запросов.

 

[HraKK]

Nelius
Как по мне, основная цель сдесь абы сделать как проще.
Что тот что тот запрос будут однофигительски быстро выполняться.

 

[Nelius]

HraKK
Ну так я потому и интересуюсь что опыта у самого мало. Спрашиваю у людей кто сталкивался, тестировал на реальных высоконагруженых проектах.
А то проектируешь по правилам все хорошо, потом появляется необходимость оптимизации запросов, работаешь с индексами, структурой запросов... потом со структурой БД и тут появляется соблазн заюзать денормализацию дабы получить прирост в производительности, но для человека с малым опытом последствия таких решений неочевидны. Может показаться что ты "выиграл", но в последствии возникнет ситуация которая покажет что "оно того не стоило" или как-то так. Это основные причины по которым я спрашиваю мнений у более опытных людей. Которым благодарен за подсказки и помощь.

 

[флоппик]

когда следует отступать от "правильного" проектирования БД ради увеличения производительности запросов.

Хех, это кстати и есть пресловутый «опыт» и «чутье», за которые профессионалы берут деньги.
А вообще, Фаулер хорошо говорил: «Не гадай, где у тебя узкое место, а возьми и померь!»

 

[HraKK]

«Не гадай, где у тебя узкое место, а возьми и померь!»

+100

и тут появляется соблазн заюзать денормализацию

Это не соблазн, а ВЫНУЖДЕННАЯ мера. У тебя она есть?

на реальных высоконагруженых проектах

У тебя реальный высоконагруженный проект?

Есть еще такое гениальное правило программиста:
Не оптимизируй. Как только это станет твоим узким местом, вот тогда и подумаешь что тебе делать.

 

[Nelius]

HraKK флоппик
Давайте немножко определимся...

«Не гадай, где у тебя узкое место, а возьми и померь!»

Я так и делаю, как бы иначе я узнал где узкое место? Если речь о том чтобы сравнить различные реализации и посмотреть что быстрее, то так я тоже делаю, НО реальные проекты,реальные ситуации и синтетические тесты это все же разные вещи.

Это не соблазн, а ВЫНУЖДЕННАЯ мера. У тебя она есть?

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

У тебя реальный высоконагруженный проект?

У меня есть такой проект, но все вопросы которые я тут поднимаю в основном касаются разработки OpenSource проекта.

 

[HraKK]

И есть желание сразу пытаться создать грамотную архитектуру

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

 

[Nelius]

Андестенд
Тогда пойду по пути "Не использовать денормализацию до тех пор, пока в полностью готовом проекте, опытным путем, при испытаниях под большой нагрузкой, не выяснится, что денормализация дает ощутимый прирост производительности и не вызывает сложных ситуаций, когда потребуется городить огород в других местах" =)))
Ну как-то так) Как думаете пойдет в качестве установки на проектирование БД? )

 

[A1x]

Автор оригинала: Nelius
pilot911
хороший вариант когда есть фиксированный набор статусов и необходимость устанавливать для записи несколько статусов одновременно.

в таких случаях обычно храню статусы в виде битовой маски в одном поле типа int. Очень удобно и нет никаких проблем с добавлением новых статусов.
также имхо совершенно лишнее создавать для имен статусов отдельную таблицу - достатосно держать их где-то в массиве (KISS)

 

[HraKK]

Nelius
Пойдет.

также имхо совершенно лишнее создавать для имен статусов отдельную таблицу - достатосно держать их где-то в массиве (KISS)

Это уже надо смотреть наскоко часто меняется и кем меняется. Если фиксированно и только _возможно_ в будущем расширение то целесообразно держать эти значения в const HIDDEN = 0 et cetere, чтоб избавиться от magic number + auto complite

 

[phprus]

С.

Предлагаю "срединный путь" -- мнемоника и экономия в одном флаконе. Тип поля CHAR(1), значения полей соответственно "P", "D", "H" и т.п.

Нет контроля значений, которое дают enum.

HraKK
А по моему pilot911 в чем-то прав. Когда у нас есть несколько флагов, которые фактически имеют тип bool и могут быть установлены в различных комбинациях, то городить здесь дополнительную таблицу и связь многие ко многим ИМХО избыточно, так как это значительно усложнит для понимания все запросы, которые будут использовать эти поля.

A1x

достатосно держать их где-то в массиве (KISS)

Когда у вас программы-клиенты к БД написаны к примеру на разных языках программирования, то возможны ситуации, что в одном коде массив поправили, а в другом забыли.

 

[HraKK]

Когда у нас есть несколько флагов, которые фактически имеют тип bool и могут быть установлены в различных комбинациях

Ага,а альтить базу не избыточно, править маппинг полей и тд. Заместо того чтоб вставить 1! лишь ряд, изза того что ктото не поймет имхо элементарный запрос. Так давайте и обьекты не использовать. + А кто должен понимать эти запросы?
А потом еще будет связь другой таблицы к этим статусам и все. Трындец.

 

[Nelius]

HraKK
Думаю то про что говорят pilot911 и phprus рассматривается в контексте того что количество статусов неизменно есть их 3 и есть до конца дней вселенной
По крайней мере при обратном очевидно что такой подход не приемлем.

Кстати что думаете по поводу подхода который предлагает A1x?
Я кстати встречал подобное решение неоднократно, причем помоему даже тут где-то в темах попадалось. Щас поищу...

 

[флоппик]

по поводу подхода который предлагает A1x?

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

 

[A1x]

Автор оригинала: HraKK
целесообразно держать эти значения в const HIDDEN = 0 et cetere, чтоб избавиться от magic number + auto complite

ниче не понял :-(