хорошо, но чуть позже тогда, а то тут есть люди, которые "профи" не могут уже почти сутки ответить на вопрос, который у "Непрофи" прям на телефоне занимает 10 минут обычно
Yii2 - атака хейтеров и что делать дальше?
Re: Yii2 - атака хейтеров и что делать дальше?
Re: Yii2 - атака хейтеров и что делать дальше?
ойййй...... когда я писал ответ (viewtopic.php?f=12&t=44836&start=320#p234254) - это не было написано .......ElisDN писал(а): ↑2018.03.17, 03:05 Типовой магазин с типовой БД. Чем https://github.com/ElisDN/yii2-demo-sho ... migrations не устраивает? Сейчас бы сделал составной pk-modification(product_id, id) для полной анрегации и FK бы делал на него.
вот так вот пока никто не видит "настоящие профи" и действуют
Re: Yii2 - атака хейтеров и что делать дальше?
То есть глядя на базу без кода Вы сразу поймёте, что она после Code First? И ещё на каком фреймворке написан сайт? Серьёзно?
Обе могут быть одинаковыми. Разница лишь в том, когда эта база построена: до придумывания кода или после. Эта, например, тоже построена чуть позже кода. Так делаю даже на AR:
Сначала создаю пустой класс. Затем с тестами или без продумываю поведение и пишу заглушки методов. Потом в эти методы начинаю вписывать внутренности. Как только понадобилось новое поле или массив, сразу прописываю его с нужным типом в PHPDoc или public-полем для тестов. Потом постепенно аналогично придумываю внутренние VO. Порой где-то внезапно напрашивается полиморфизм в виде стратегии, о чём раньше не думал. Где-то хочется коллекцию вместо массива выделить...
И потом уже, когда всё придумано, отрефакторено и проверено, копирую готовые списки полей из PHPDoc в миграцию. И таблицы получаются сразу на 100% рабочими, и без лишних полей. И все доработки уже учтены.
Захочется оптимизировать БД - заменю EAV с таблицами на JSON, добавив json_encode и гидрацию в afterFind/beforeSave без переписывания остального кода и тестов. Захочется формат даты в полях поменять - без проблем, так как методы работают с DateTimeImmutable.
В реляционных БД всё типично: кортежи, индексы, ограничения и нормализация. Так что не знаю, чего Вы ждёте. Что у меня в схеме будут какие-то удивительные ключи и связи?
Ну и Вы не путайте структуры и диаграммы.
Re: Yii2 - атака хейтеров и что делать дальше?
Ну да. Профи ставят составной FK на PK для ссылки по ID на внутреннюю (неуникальную глобально) сущность агрегата, как я ответил Вам вначале с этим же примером для Doctrine. И дружно ржут над вашим составным FK не на PK. Всё логично. Противоречий не вижу.
Re: Yii2 - атака хейтеров и что делать дальше?
эммм..... профи с нетрадиционными фантазиями вечно все путает, и не удивительно, таких примеров сейчас в нашей жизни много
вы трындеть то может закончите и представите решение ? а ?
Re: Yii2 - атака хейтеров и что делать дальше?
вы о себе во множественном числе ?
Re: Yii2 - атака хейтеров и что делать дальше?
о ужас.......... вот что бывает с профи с нетрадиционными фантазиями...
структуру можно описать, а можно прочесть по диаграмме - и тот и другой вариант - подходит
а миграции - это дифы, по ним можно прочесть структуру только если применишь все.
разница есть профи ?
уже более суток трындишь а результата ноль
Re: Yii2 - атака хейтеров и что делать дальше?
для особо "не профи" поподробнее можно? вы же профи, для вас это не должно быть работой на еще одни сутки
Re: Yii2 - атака хейтеров и что делать дальше?
такое ощущение что "профи" занервничал, как обычно студенты на экзамене когда не знают правы или нет - начинают вокруг да около ходить
Re: Yii2 - атака хейтеров и что делать дальше?
Ну вот об этом, собственно, и говорил:
Вы и за вторую неделю не поняли, почему над вашим FK профи ржут. Теперь из-за этого же не понимаете, почему над моим FK не ржут. Придумываете новые перлы, но не помогает. Вот досада-то... Да?
Re: Yii2 - атака хейтеров и что делать дальше?
досада то что диалог с вами не конструктивен в принципе.
то у вас гейские фантазии
то какие то разрозненые мысли не понятно о чем
то "я сказал надо мной не ржут" и "над вами все ржут". кто ржет то ? а ? такие же геи как ты ?
трындежь ниочем какими то абстракциями ниочем
ты обоснуй свою позицию, профи фигов,
а пока я вынужден прекратить данную дискусию в силу ее бесполезности
Re: Yii2 - атака хейтеров и что делать дальше?
Неее... Направление я дал, как смог. Без спойлеров. До остального вы должны сами дойти. Осознать, за что над вами стебутся. Только так профессионалом в теории и практике станете. А то смайлики и геи вам читать мои сообщения мешают.
Ну хорошо. Вам не поможет, а мне и читателям дискуссия оказалась полезна. Столько материалов и философии здесь выдали, отвечая на ваши набросы. Спасибо за вклад!
Re: Yii2 - атака хейтеров и что делать дальше?
собственно что и требовалось доказать
дискуссия закончена, ElisDN показал себя не как профессионал который может быстро и качественно решить задачу или конкретно ответить на вопрос, а как девочка которая болтает что ни попадя после первого стаканчика, говоря о себе во множественном лице, путая все что только можно и нельзя и при этом называя себя профессионалкой.
а потенциальных слушателей унылых курсов от девочки профессионалки с растройствами психики я бы предостерег от контактов
дискуссия закончена, ElisDN показал себя не как профессионал который может быстро и качественно решить задачу или конкретно ответить на вопрос, а как девочка которая болтает что ни попадя после первого стаканчика, говоря о себе во множественном лице, путая все что только можно и нельзя и при этом называя себя профессионалкой.
а потенциальных слушателей унылых курсов от девочки профессионалки с растройствами психики я бы предостерег от контактов
Re: Yii2 - атака хейтеров и что делать дальше?
итак
для начала фокус номер один, внимательно следите за руками
перечитайте еще раз, внимательно. и оттветьте на вопрос - где я обещал что дам задачу на составной FK не на PK ? более того я обрезал цитату ElisDN именно для того чтоб подчеркнуть это. но у него же чувство собственной офигенности разум туманит, так что это нормально.
он же так до самого конца был в этом уверен
для начала фокус номер один, внимательно следите за руками
ничего подозрительного ? профессионалка, ты тоже ничего не замечаешь ?
перечитайте еще раз, внимательно. и оттветьте на вопрос - где я обещал что дам задачу на составной FK не на PK ? более того я обрезал цитату ElisDN именно для того чтоб подчеркнуть это. но у него же чувство собственной офигенности разум туманит, так что это нормально.
он же так до самого конца был в этом уверен
Re: Yii2 - атака хейтеров и что делать дальше?
идем дальше. фокус номер 2
ожидаемо что именно похожий пример покажет наш "профи", поэтому буду апеллировать к нему, поскольку он настойчиво утверждал что это нужный пример:
https://github.com/ElisDN/yii2-demo-sho ... le.php#L16
https://github.com/ElisDN/yii2-demo-sho ... le.php#L17
https://github.com/ElisDN/yii2-demo-sho ... le.php#L18
https://github.com/ElisDN/yii2-demo-sho ... le.php#L19
https://github.com/ElisDN/yii2-demo-sho ... le.php#L20
идет дублирование информации ? а ? ты же говорил что то там про нормализацию ? а ? а про накладные расходы ? сколько дополнительно места ты теряешь имея эти строки ? а их еще заполнить надо....
так что же получается... сама себе противоречишь ?
пс. не надо мне говорить что использование этих полей - есть необходимость. я это прекрасно знаю. я говорю про то - что в реальности в системе (кроме сайтиков на 5 страничек) всегда будут накладные расходы которые нарушат вашу "нормализацию", тогда вы видимо будете уже не профи
пс2.
самая нормализованная из представленных вариантов схема у
а самая не нормальная схема у samdark судя по той же оценке потому что там в json можно напихать много чего дулирующего имеющиеся данные
@andku83 и @samdark против Ваших схем и Вас лично ничего не имею,
схема samdark номер 1 по мне - наиболее правильная
ожидаемо что именно похожий пример покажет наш "профи", поэтому буду апеллировать к нему, поскольку он настойчиво утверждал что это нужный пример:
а чуть ранее наш "профи" много раз говорил про нормализацию, отсутствующие накладные расходы и дополнительные телодвижения и другие неубедительные доводы, которые он считал являются признаком настоящего профи.... но тут возникает вопрос.... умняшка, а зачем у тебя вот тутElisDN писал(а): ↑2018.03.17, 03:05 Типовой магазин с типовой БД. Чем https://github.com/ElisDN/yii2-demo-sho ... migrations не устраивает? Сейчас бы сделал составной pk-modification(product_id, id) для полной анрегации и FK бы делал на него.
https://github.com/ElisDN/yii2-demo-sho ... le.php#L16
https://github.com/ElisDN/yii2-demo-sho ... le.php#L17
https://github.com/ElisDN/yii2-demo-sho ... le.php#L18
https://github.com/ElisDN/yii2-demo-sho ... le.php#L19
https://github.com/ElisDN/yii2-demo-sho ... le.php#L20
идет дублирование информации ? а ? ты же говорил что то там про нормализацию ? а ? а про накладные расходы ? сколько дополнительно места ты теряешь имея эти строки ? а их еще заполнить надо....
так что же получается... сама себе противоречишь ?
пс. не надо мне говорить что использование этих полей - есть необходимость. я это прекрасно знаю. я говорю про то - что в реальности в системе (кроме сайтиков на 5 страничек) всегда будут накладные расходы которые нарушат вашу "нормализацию", тогда вы видимо будете уже не профи
пс2.
самая нормализованная из представленных вариантов схема у
поэтому судя по шкале "оценки" нашего профи - andku83 гораздо больший профессионал чем ElisDN
а самая не нормальная схема у samdark судя по той же оценке потому что там в json можно напихать много чего дулирующего имеющиеся данные
@andku83 и @samdark против Ваших схем и Вас лично ничего не имею,
схема samdark номер 1 по мне - наиболее правильная
Re: Yii2 - атака хейтеров и что делать дальше?
фокус 3
PK и не PK
есть таблица А(id PK, type_id, name, .... )
логично сделать следующее утверждение, что в если в таблице А есть поле id которое является уникальным, то независимо от того что будет в поле type_id - пара (id, type_id) будет всегда уникальна.
но, если вы хотите сослаться на эту таблицу по FK(id, type_id) то вам придется в таблицу А добавить UNIQUE(id, type_id) хотя казалось бы смысла в этом нет.
таким образом формально составной FK уже не PK, а казалось бы "лишняя запчасть" , но лично я не вижу необходимости делать PK на 2 поля без особой надобности. а делать 2 констрейта по PK и FK ссылающихся на эту таблицу - это уже слишком.
теперь вопрос - зачем тебе "вася" эти фк нужны вообще
ответ очень прост, когда у тебя 4-5-6 таблиц "нормализованы" и при этом тебе из таблицы номер 1 надо получить данные сответствующей сущности из таблицы номер 6 - то без знаний в таблице 1 о сущности в таблице 6 - вам придется пройтись по всем 6 таблицам. точно так же как предлагала наша умняшка. когда речь идет о хайлоаде то тут надо очень серьезно подумать какие операции важней (чтения или записи). а если FK не будет, то у вас есть шанс по ошибке собственной криворукости достичь не консистентности данных. лишний барьер не помешает.
да, накладные расходы есть, а где их нет.
но когда отвечаешь за проект в котором хранятся данные например о всех наркотиках региона... то мне плевать на эти накладные расходы и то что вот таким вот "умняшкам" с опытом сайтиков на 5 страничек чтото там не понравится
+ поле входящее в FK может быть не только типа bigint или uuid, а например нести полезную нагрузку, значения типа png, gif, bmp, docx, pdf и тд
пс. я не говорю что ВАМ это нужно. я говорю про то что такое может понадобится, и если полпроекта уже сделал на кривом доктрине и тут оказалось что в нем ничего подобного нельзя то нафиг мне такой доктрин
PK и не PK
есть таблица А(id PK, type_id, name, .... )
логично сделать следующее утверждение, что в если в таблице А есть поле id которое является уникальным, то независимо от того что будет в поле type_id - пара (id, type_id) будет всегда уникальна.
но, если вы хотите сослаться на эту таблицу по FK(id, type_id) то вам придется в таблицу А добавить UNIQUE(id, type_id) хотя казалось бы смысла в этом нет.
таким образом формально составной FK уже не PK, а казалось бы "лишняя запчасть" , но лично я не вижу необходимости делать PK на 2 поля без особой надобности. а делать 2 констрейта по PK и FK ссылающихся на эту таблицу - это уже слишком.
теперь вопрос - зачем тебе "вася" эти фк нужны вообще
ответ очень прост, когда у тебя 4-5-6 таблиц "нормализованы" и при этом тебе из таблицы номер 1 надо получить данные сответствующей сущности из таблицы номер 6 - то без знаний в таблице 1 о сущности в таблице 6 - вам придется пройтись по всем 6 таблицам. точно так же как предлагала наша умняшка. когда речь идет о хайлоаде то тут надо очень серьезно подумать какие операции важней (чтения или записи). а если FK не будет, то у вас есть шанс по ошибке собственной криворукости достичь не консистентности данных. лишний барьер не помешает.
да, накладные расходы есть, а где их нет.
но когда отвечаешь за проект в котором хранятся данные например о всех наркотиках региона... то мне плевать на эти накладные расходы и то что вот таким вот "умняшкам" с опытом сайтиков на 5 страничек чтото там не понравится
+ поле входящее в FK может быть не только типа bigint или uuid, а например нести полезную нагрузку, значения типа png, gif, bmp, docx, pdf и тд
пс. я не говорю что ВАМ это нужно. я говорю про то что такое может понадобится, и если полпроекта уже сделал на кривом доктрине и тут оказалось что в нем ничего подобного нельзя то нафиг мне такой доктрин
Re: Yii2 - атака хейтеров и что делать дальше?
> ты девочка
> ты гей
> у тебя растройства психики
Мощная аргументация...
> ты гей
> у тебя растройства психики
Мощная аргументация...
Re: Yii2 - атака хейтеров и что делать дальше?
бонус
накладные расходы в виде 1 таблицы (product), агрегирующей общие свойства, но гибкость не ограничена, консистентность констрейтами соблюдена
пс. казалось бы а причет тут составной FK
держи, примерно так
Код: Выделить всё
$this->createTable('{{%product}}', [
'id' => $this->uuidPk4(),
'type_id' => $this->smallint()->notNull(),
'name' => $this->string(64)->notNull(),
.......
$this->uniqueConstraint(['id', 'type_id']),
]);
$this->createTable('{{%product_type_1}}', [
'id' => $this->uuid4()->notNull(),
'type_id' => $this->smallint()->notNull(),
'field11' => $this->string(64)->notNull(),
'field12' => $this->string(64)->notNull(),
.......
$this->checkConstraint('type_id = 1'),
$this->foreignKey(['id', 'type_id'], '{{%product}}', ['id', 'type_id']),
]);
$this->createTable('{{%product_type_2}}', [
'id' => $this->uuid4()->notNull(),
'type_id' => $this->smallint()->notNull(),
'field21' => $this->string(64)->notNull(),
'field22' => $this->string(64)->notNull(),
.......
$this->checkConstraint('type_id = 2'),
$this->foreignKey(['id', 'type_id'], '{{%product}}', ['id', 'type_id']),
]);
$this->createTable('{{%product_type_3}}', [
'id' => $this->uuid4()->notNull(),
'type_id' => $this->smallint()->notNull(),
'field31' => $this->string(64)->notNull(),
'field32' => $this->string(64)->notNull(),
.......
$this->checkConstraint('type_id = 3'),
$this->foreignKey(['id', 'type_id'], '{{%product}}', ['id', 'type_id']),
]);
.........
$this->createTable('{{%incoice}}', [
'id' => $this->uuidPk4(),
'field1' => $this->string(64)->notNull(),
'field2' => $this->string(64)->notNull(),
'field3' => $this->string(64)->notNull(),
.......
]);
$this->createTable('{{%incoice_product}}', [
'incoice_id' => $this->uuid4()->notNull(),
'product_id' => $this->uuid4()->notNull(),
$this->primaryKey(['incoice_id', 'product_id']),
$this->foreignKey(['incoice_id'], '{{%incoice}}', ['incoice_id']),
$this->foreignKey(['product_id'], '{{%product}}', ['product_id']),
]);
пс. казалось бы а причет тут составной FK
Последний раз редактировалось sm-vasya 2018.03.17, 21:52, всего редактировалось 2 раза.
Re: Yii2 - атака хейтеров и что делать дальше?
Итак, слежу за руками:
Эх, Уася, Уася...