Не катит вообще х)

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

)) тогда все понятно, иначе бы самобичевание пришлось устроить

пятница же!

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

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

Это для тех, у кого адекватные родители.

пятница же!

Я вас огорчу, четверг

Я вас огорчу, четверг

ой да ладно тебе

Это для тех, у кого адекватные родители.

ну тогда сделаем еще лучше. Смотрел "планета k pax"?

Есть три таблицы. Products (id, name), Properties (id, name), Values (id, value, product_id, property_id). В products хранятся два дилдо: розовый и синий. В пропертис: ширина и длина. Собственно там где values хранится длина и ширина розового и синего дилдо. Длина и ширина одного равны 10 и 15. Длина и ширина второго 15 и 10. Вопрос, что с этими ребятами не так? А если все так, то как узнать, какой дилдо имеет размеры 15 в длину и 10 в ширину.

джойн сам на себя, см EAV

Это для тех, у кого адекватные родители.

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

но есть константа DIRECTORY_SEPARATOR которая содержит верный слеш для ОС

я тут видел код, который ос определяет именно по этой константе

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

гений должен быть голодный! ;)

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

на пхп небось пишет)

на пхп небось пишет)

хахахаха

на пхп небось пишет)

.net-ы за деньги делает

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

мотивирует х)

.net-ы за деньги делает

эх не удалась шутка)

гений должен быть голодный! ;)

это что-то из серии "все дети особенные"?)

Самое смешное это то, что в 1 курсе был беглый HTML/CSS и про базы данных (не знаю, как всё это связано), при том если про HTML/CSS хотя бы на уровне создания табличек было, то с БД было про MS Access (или как пишется?) и MySQL на уровне "в базе данных хранится информация, она в таблицах". Во втором вообще рассказывают про архиваторы файлов вроде 7zip, HaoZIP, и WinRaR, смешно что всё это конспектировать надо. Ну и то, что на первом курсе C++ на уровне синтаксиса (что такое переменная и функция конспектировали), на втором вроде C#, опять же, должен быть на на уровне того же синтаксиса (второй курс только начался). Ну и сейчас кульминация. Прям взрыв мозга нахрен. Нам как-то на паре включили уроки из канала ХАУДИ ХО и его урок PHP ЗА ЧАС от профессионала. =______= Ну хоть на парах играли в Сталкер.

джойн сам на себя, см EAV

Благодарю за ответ. Но, кажется, что-то здесь не так

а нам про типы мониторов рассказывали на втором курсе. жесть

Благодарю за ответ. Но, кажется, что-то здесь не так

здесь не так EAV - весьма проблемный способ хранения для выборок, по-этому параметры, по которым активно используется выборки выносят как колонки в таблицу продуктов, ну или используют не реляционную субд для поиска

здесь не так EAV - весьма проблемный способ хранения для выборок, по-этому параметры, по которым активно используется выборки выносят как колонки в таблицу продуктов, ну или используют не реляционную субд для поиска

+++

здесь не так EAV - весьма проблемный способ хранения для выборок, по-этому параметры, по которым активно используется выборки выносят как колонки в таблицу продуктов, ну или используют не реляционную субд для поиска

А если колонок вариантов параметров очень много и все хранить в таблице продуктов не вариантов?

не вариант*

а нам про типы мониторов рассказывали на втором курсе. жесть

А у нас на направлении бизнес-информатика в РЭУ Плеханова со мной учится парень на 4ом курсе который не умеет округлять десятичные дроби. Вот чему и как нас учат

А если колонок вариантов параметров очень много и все хранить в таблице продуктов не вариантов?

тогда страдать потом на выборках из eav

А если колонок вариантов параметров очень много и все хранить в таблице продуктов не вариантов?

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

ну или если нагрузка на базу небольшая - то джойны в общем тоже работают

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

стране не нужны умные люди

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

Очень много товаров. Очень много товаров с уникальными характеристиками. Спасибо за ответ.

Очень много товаров. Очень много товаров с уникальными характеристиками. Спасибо за ответ.

nullable

свойства в таблице

единственное где это проблемно это если надо характеристики в админке добавлять

В смысле в товаре создать сотни nullable колонок?)

да это будет удобней потом

сейчас найду презентацию

и там основные способы как не юзать антипаттерн eav

и что вместо него можно делать

а что если параметры создаются со временем новые и удаляются. мы постоянно удаляем и добавляем nullable колонки?)

один из вариантов это куча колонок со значением null

как вариант, но так можно до таблицы с сотнями колонок дойти... не очнь удобно... или вообще упереться в лимит ;)

а что если параметры создаются со временем новые и удаляются. мы постоянно удаляем и добавляем nullable колонки?)

неа

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

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

Если нужно динамически добавлять свойства из админки - то решение с nullable хреновое. Плюс, обычно поля храняться выровненые в БД, следовательно каждое nullable будет жрать столько же диска, сколько и забитое. Если товары очень похожи(таблица не будет разреженой) и не нужно менять проперти - то можно попробывать. Вообще сейчас EAV во всех готовых CMSмагазинах - видимо, пока что лучше не придумали

и рядом хранить динамические, которые нигде не юзаются только для отображения

Если нужно динамически добавлять свойства из админки - то решение с nullable хреновое. Плюс, обычно поля храняться выровненые в БД, следовательно каждое nullable будет жрать столько же диска, сколько и забитое. Если товары очень похожи(таблица не будет разреженой) и не нужно менять проперти - то можно попробывать. Вообще сейчас EAV во всех готовых CMSмагазинах - видимо, пока что лучше не придумали

ну давай расскажи про varchar который 99% случаев юзается у людей

вот интересные слайды на эту тему https://www.slideshare.net/billkarwin/extensible-data-modeling

Если нужно динамически добавлять свойства из админки - то решение с nullable хреновое. Плюс, обычно поля храняться выровненые в БД, следовательно каждое nullable будет жрать столько же диска, сколько и забитое. Если товары очень похожи(таблица не будет разреженой) и не нужно менять проперти - то можно попробывать. Вообще сейчас EAV во всех готовых CMSмагазинах - видимо, пока что лучше не придумали

выровненость поля зависит от типа

и не все типы хранятся выровненно

ну давай расскажи про varchar который 99% случаев юзается у людей

Ну, я подразумевал инты, даты, и короткие строки. Да, варчар не выравнивается.

и это прежде временная оптимизация ... (с.) Кнут

ну давай расскажи про varchar который 99% случаев юзается у людей

куда как интереснее рассказать про людей, которые меняют N в int(N) и на что-то надяются ;)

Ну, я подразумевал инты, даты, и короткие строки. Да, варчар не выравнивается.

здесь согласен, но имхо цена ниже чем потом ебаться с поддержкой

и это надо учитывать в реально хайлоуде но не тут

оптимизацией надо заниматься когда есть нагрузка

Всем спасибо) Если найду интересный способ решения задачи, буду держать в курсе. Есть инфа, что задачу еще объяснил не совсем понятно.

вот очень хорошая презентация

https://www.slideshare.net/billkarwin/sql-antipatterns-strike-back/16-EntityAttributeValue_If_you_try_and

как раз открыл на eav

интересный способ - это эластик рядышком, а все остальное - костыли и онанизм ;)

там человек показывает разные подходы

но есть случаи когда да потребуется что то рядышком

но тут на презентции основные проблемы eav показаны и как этого избежать

можно еще взять постгрес и запихнуть все в jsonb :)

и это прежде временная оптимизация ... (с.) Кнут

Странное понятие преждевременной оптимизации(ПО). Хотя твое понятие ПО для меня и должно бысть странным, ведь нигде толком ПО не описана, и каждый понимает по своему. Как по мне отказ от откровенно хреновая архитектура (разреженная таблица), с учетом того что я знаю (много РАЗНЫХ товаров, и динамическое добавление свойств) на начальном этапе - это не ПО. Ведь если я сча ошибусь, то потом толко переписать нахуй. (Не представляю себе постепенного рефакторинга с разреженной таблицы к EAV + ElasticSearch. А ты представляешь?) ПО - это когда я мелкие реализации, начинаю оптимизировать прямо сейчас, когда смогу сделать это потом, а сейчас можно и абыкак (пример разворачивания циклов, или выбора оптимального типа переменной для текущей задачи. IMHO

Странное понятие преждевременной оптимизации(ПО). Хотя твое понятие ПО для меня и должно бысть странным, ведь нигде толком ПО не описана, и каждый понимает по своему. Как по мне отказ от откровенно хреновая архитектура (разреженная таблица), с учетом того что я знаю (много РАЗНЫХ товаров, и динамическое добавление свойств) на начальном этапе - это не ПО. Ведь если я сча ошибусь, то потом толко переписать нахуй. (Не представляю себе постепенного рефакторинга с разреженной таблицы к EAV + ElasticSearch. А ты представляешь?) ПО - это когда я мелкие реализации, начинаю оптимизировать прямо сейчас, когда смогу сделать это потом, а сейчас можно и абыкак (пример разворачивания циклов, или выбора оптимального типа переменной для текущей задачи. IMHO

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

это даже не знаю как назвать, плюсом или минусом

посмотри слайды

про eav там их штук 5

и там четко написано когда надо eav а когда без этого можно обойтись и что надо стараться обходиться без этого

основные проблемы eav там тоже хорошо показаны у eav

16 слайдов это с условием что показаны предложения как не юзать eav

Да, я посмотрел. Слишком академический пример. Когда я спрашивал про рефакторинг, я имел ввиду реальный магазин, где у тебя уже есть пару десятков запросов. Хрен ты их постепенно рефакторнешь.... Это координально разные запросы. Это фундаментальный вопрос. EAV или не EAV нужно выбирать сразу. Мое мнение после слайдов не поменялось.

Да, я посмотрел. Слишком академический пример. Когда я спрашивал про рефакторинг, я имел ввиду реальный магазин, где у тебя уже есть пару десятков запросов. Хрен ты их постепенно рефакторнешь.... Это координально разные запросы. Это фундаментальный вопрос. EAV или не EAV нужно выбирать сразу. Мое мнение после слайдов не поменялось.

ну тогда юзай eav это твой выбор, кто мы такие чтобы менять твое мнение

тебе сказали плюсы и минусы выбирать тебе, тебе с этим кодом работать

Да, я посмотрел. Слишком академический пример. Когда я спрашивал про рефакторинг, я имел ввиду реальный магазин, где у тебя уже есть пару десятков запросов. Хрен ты их постепенно рефакторнешь.... Это координально разные запросы. Это фундаментальный вопрос. EAV или не EAV нужно выбирать сразу. Мое мнение после слайдов не поменялось.

это всего-лишь магазин :)

Я не говорил его юзать.... хм... читай внимательно. Я говорил что решать нужно в начале, ибо это не зарефакторишь.

тебе сказали плюсы и минусы выбирать тебе, тебе с этим кодом работать

Солидарен польностью.

Я не говорил его юзать.... хм... читай внимательно. Я говорил что решать нужно в начале, ибо это не зарефакторишь.

зарефакторить можно все

вопрос трудозатрат

Темболее то мне он нахуй не нужен сейчас ГЫГЫ

а в чем проблема от разреженной таблицы перейти к EAV+Elastic? ;)

а в чем проблема от разреженной таблицы перейти к EAV+Elastic? ;)

надо работать)

ну блин... это да ;) я бы сказал - нужно обосновать бизнесу - какого фига затраты и почему сразу не сделали нормально ;)

Солидарен польностью.

просто с опытом люди делают разряженную таблицу или featch table и делают eav

вопрос трудозатрат

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

только поиска по eav ничего не делают его просто отображают на странице товара

в деталях ни поиска ни фильтрации

всякие кривые cms просто на лету таблицу через alter table модифицируют

на каждый товар своя таблица

добавили колонку, cms вносит колонку в бд через alter table

и получается куча разных таблиц

и живут, причем так делает большинство cms

хорошо это или плохо вопрос открытый