Костыль не костыль. Есть второй вариант — Для каждого типа товара своя таблица… Но сколько типов товаров и сколько таблиц? Это тоже костыль. Для реляционных БД нет нормального решения. Мне нравится EAV (след. сайт как раз буду делать с ним)
На StackOverflow как раз написаны "+" и "-". И ниже еще обсуждение
Не совсем. Мне не нужна копия базы. В офисе будет другая база. Типо CRM. Т.е. в ней конечно будут клиенты, но расширенные. Например рост, фотография, прическа, марка машины.
Клиенты на сайте это не видят, это только для нас. Но обновить фамилию или телефон нужно. Чтобы и там и там было обновлено
С такой задачей сталкиваюсь впервые. В универе делал гораздо проще и не для бизнеса :) Хотелось бы что-нибудь быстро прочитать по этой теме. Банально — как правильно составить граф. Полный перебор то я организовать сумею))
Для начала видимо подойдет просто распределение передач по курьерам и оптимальные ходы по метро + переезд с одной ветки на другую по верху если они рядом
Сейчас EAV проще внедрить. Товаров уже куча. заказы есть. это переделывать очень много. в EAV я кое что смогу вшить в код, например не PropertyName а PropertyID (а это enum). А что почитать про кеширование? Например есть 5000 товаров, их все закешировать и обновлять кеш при изменении товара?
Именно такого 4-го пункта я и ждал. Я уж думал что совсем все «привет» :) все верно. С 3-м пока не заморачивался, не такие важные сайты, но там есть простор для фантазии
На StackOverflow как раз написаны "+" и "-". И ниже еще обсуждение