Я так и делал, скорее больше вопрос сколько времени переходить с С++ к примеру на С# примерно по времени.
у некоторых компаний дивиденды выплачиваются за квартал,а не за год. Но мысль я уловил спасибо.
В долгосрочной перспективе если работая каждый месяц вкладывать хотя бы 10000р. + дивиденды(хоть и не большие) то через 10 лет дивиденды будут составлять 100тыс.руб, как по мне это не плохо если тебе около 20 лет, можно на пенсию выйти в 30+ :)
Но опять же - речь была о правильной структуре, поэтому я говорил о правильной структуре с точки зрения канонов.
пример плохой реализации о которой я говорил можете увидеть в ответе ниже пользователя alex-1917 на втором скриншоте, там как раз создана эта одна табличка где все хранится в виде строк(product_options_values)
Еще один пример правильной реализации это создание для каждого подтипа отдельной таблицы. Этот подход хорош тем что сохраняются все преимущества реляционных СУБД, но уместно применим только когда количество подтипов не слишком большое. Вот описание подхода из этой же книги
Пример неправильного воплощения/реализации Вы можете увидеть на первом скриншоте который я скидывал: там eav воплощен в виде таблицы вида сущность-атрибут-значение(в примере из книги это issue_id(сущность)-attr_name(атрибут)-attr_value(значение)). Такая реализация является крайне плохой, потому что приходится хранить все значения в виде строк, в том числе числа с датами, и все в одном столбце. При таком подходе мы не знаем типов значений, не можем вводить необходимости уникальности значений для определенных атрибутов и прочие вытекающие, то есть ни о какой целостности данных не может быть речи.
Пример правильного подхода(средствами реляционных бд) реализации при условии большого количества типов Вы можете увидеть на втором скриншоте, который я кидал: данный подход подразумевает хранение атрибутов в виде json или xml. Тут тоже много недостатков и лишаемся многого, но этот подход считается наиболее оптимальным когда много типов.
я готов дискутировать.
Есть отвратительные реализации этой модели, которыми грешат многие разработчики, которые сводят на нет все преимущества реляционных СУБД.
Но есть и правильные подходы, которые во многом зависят от предметной области.
Из этой же книги, из этого же раздела, целиком посвященного EAV, что вы тоже назвали "нe eav"
А то, что Вы не увидели в тех примерах EAV, свидетельствует о пробелах в Ваших знаниях.
в удаленном ответе все было более чем по существу(успел застать)
Лишаемся многих преимуществ реляционного подхода
Было еще желание сделать нечто, что не стыдно показать на собеседовании, но с такими "успехами", понятно что эта цель не достигнута.
командую строку?
гм.
много ли админов умеют все без GUI делать под Windows...