@symfony_php

« Назад

Страница 130 из 1418

Далее »

Sergey

08.03.2017
19:31:12

такое себе удовольствие

Timur

08.03.2017
19:32:07

Не сделает, если запросы правильно написать

Sergey

08.03.2017
19:32:24

ну тебе придется везде тулить этот джоин

даже если он не нужен

Google

Timur

08.03.2017
19:33:15

Джоин то делать придется, но чувак волнуется, что из-за этих джоинов производительность упадет, в чем я очень сомневаюсь

Yuriy

08.03.2017
19:33:58

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

Sergey

08.03.2017
19:35:10

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

Timur

08.03.2017
19:38:09

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

тогда подключить к User и Manager и Customer

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

Ничего страшного в этих джоинах нет, если у тебя не происходит по 100 таких запросов в секунду

Sergey

08.03.2017
19:39:38

тогда подключить к User и Manager и Customer

если у тебя общая таблица юзеров, то так и будет. а если раздельная - то привет костыли и подпорки

Timur

08.03.2017
19:40:15

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

Это твой личный проект или за бабло делаешь?

Yuriy

08.03.2017
19:42:49

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

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

Timur

08.03.2017
19:53:47

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

Вообще, я не ставил перед собой вопрос, стоит ли делать отдельные таблицы с отдельными точками входа. У меня было два варианта: 1) Либо тупо создать одну таблицу и все хранить там. Минус в том, что большая часть таблицы будет всегда пустой. Но это тоже так... сомнительный минус. 2) Сделать так, как я описал выше

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

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

Sergey

08.03.2017
19:58:07

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

Timur

08.03.2017
19:58:30

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

Пруфы?

Google

Sergey

08.03.2017
19:59:05

ты делаешь выборку на 100 записей, у тебя в таблице 10 полей или 50 полей. что отработает быстрее?

а если не 100 записей, а больше?

Timur

08.03.2017
20:00:53

а если не 100 записей, а больше?

Этими вопросами я и задавался, когда гуглил. Искал всякие статистики. Да, отвечая на твой вопрос, естественно если 10 полей, будет быстрее. Но насколько быстрее? На 100 наносекунд? И стоят ли эти 100 наносекунд твоего красноглазия?

Sergey

08.03.2017
20:01:18

поверь это далеко не 100 наносекунд

Timur

08.03.2017
20:01:31

Не поверю. Пруфы давай или истории из жизни)

Sergey

08.03.2017
20:01:43

http://ocramius.github.io/blog/doctrine-orm-optimization-hydration/

похожий кейс

Alan

08.03.2017
20:02:07

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

хотя если уверен и осознанно то и в денормализации ниче плохого нет

Timur

08.03.2017
20:03:56

http://ocramius.github.io/blog/doctrine-orm-optimization-hydration/

Эт не пруф. Там нет ничего про количество полей

Sergey

08.03.2017
20:07:06

100х10 = 1к итераций против 100х100 - 10к итераций на гидрацию как минимум если у тебя будет только User отвечающий за несколько типов, у тебя повсюду будут проверки в духе if(!$user->isCustomer()){...}, хотя можно было б явно задавать тип и будет поменьше мусора и шансов на ошибку

бенчмарк позже сделаю

Sergey

08.03.2017
20:08:35

А можно узнать, зачем тебе понадобилось две разные таблицы?

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

иначе "админ" был бы просто ролью пользователя

Timur

08.03.2017
20:09:33

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

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

и это такой пользователь

Yuriy

08.03.2017
20:16:23

Sergey Protko а можно узнать твое мнение, рознести админов от юзеров по разным таблицам или использовать одну связующуя как было предложено ранее?

Jerry

08.03.2017
21:40:00

Ты можешь создать три сущности: 1) базовую User, которая содержит общую информацию, которая есть у всех пользователей, независимо от типа 2) Customer (например). Эта сущность содержит специфическую для этого пользователя информацию 3) Admin - также, содержит специфическую для админа информацию. Между сущностями делаешь связи oneToOne User <- one-to-one -> Customer User <- one-to-one -> Admin Когда пользователь регистрируется, создается User и к нему привязывается нужная тебе сущность, либо Customer либо Admin

Polymorphic не?

http://docs.doctrine-project.org/projects/doctrine-orm/en/latest/reference/inheritance-mapping.html

Sergey

08.03.2017
22:29:27

Sergey Protko а можно узнать твое мнение, рознести админов от юзеров по разным таблицам или использовать одну связующуя как было предложено ранее?

зависит от требований.

Google

Sergey

08.03.2017
22:29:53

Polymorphic не?

ты про тот булшит что в ларавели?

Big_Shark

08.03.2017
22:30:08

ты про тот булшит что в ларавели?

Так так так, это вы тут про что?

Sergey

08.03.2017
22:30:52

Так так так, это вы тут про что?

хз, подозреваю что человек имел ввиду "полиморфные связи" из элоквента

Big_Shark

08.03.2017
22:31:43

хз, подозреваю что человек имел ввиду "полиморфные связи" из элоквента

Ааа, я както пытался нагуглить кто их еще так называет кроме ларавеля, не смог найти.

Sergey

08.03.2017
22:32:15

Ааа, я както пытался нагуглить кто их еще так называет кроме ларавеля, не смог найти.

я уже плохо помню описание, помню что когда впервый раз читал про них не нашел ничего "полиморфного"

Big_Shark

08.03.2017
22:34:17

я уже плохо помню описание, помню что когда впервый раз читал про них не нашел ничего "полиморфного"

типа есть табличка, и в ней есть 2 поля, типа и ид, и эти поля указывают на то с чем связана данная запись. Допустим есть табличка картинок и они могут быть привязаны к статье, и к новости, и тогда у одной картинки может быть news в типе, а у другой article

Jerry

08.03.2017
22:34:22

http://docs.doctrine-project.org/projects/doctrine-orm/en/latest/reference/inheritance-mapping.html это как раз то что нужно человеку

Sergey

08.03.2017
22:34:37

http://docs.doctrine-project.org/projects/doctrine-orm/en/latest/reference/inheritance-mapping.html это как раз то что нужно человеку

нет, не нужно лепить туда наследование

точнее даже не так.... всегда старайся избегать наследования

настолько насколько можно

в контексте сущностей оно хорошо ложится на ситуации когда есть одни и те же данные но нужно разное поведение

это как по мне весьма редкий кейс

Big_Shark

08.03.2017
22:36:23

это как по мне весьма редкий кейс

Зависит от задачи

Sergey

08.03.2017
22:43:49

Зависит от задачи

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

Jerry

08.03.2017
23:07:55

точнее даже не так.... всегда старайся избегать наследования

Почему? Сколько решали задач на проектах таким образом и все нормально.

Sergey

08.03.2017
23:08:24

Почему? Сколько решали задач на проектах таким образом и все нормально.

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

ну и опять же - задачи бывают разными

я тоже наследование таблиц юзаю но очень редко

и когда вижу в этом профит

p.s. если что - я из тех недолеких людей которые считают что "если ты лепишь наследование - попробуй подумать минут 10 хотя бы а надо ли"

Google

Sergey

08.03.2017
23:11:12

если тебе надо наследование типов - тогда скорее всего ок. А если ты дублирование устраняешь - скорее всего ты где-то свернул не туда

Jerry

08.03.2017
23:11:19

Чес слово, времени на демагогию нет)

Sergey

08.03.2017
23:15:35

Чес слово, времени на демагогию нет)

ну так не разводи)

делать одну сущность User или две (User и Admin) определяется исключительно циклом жизни оных

если у тебя юзеры и админы появляются одинаково - например регистрируются

то тогда логично делать их одним классом.

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

но... большинство тех кто юзает доктрину проектируют таблички в базе так что...

Admin

ERROR: S client not available

Sergey

08.03.2017
23:18:29

ну и могу привести массу примеров из своих проектов где делать одну сущность User является плохой идеей)

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

Big_Shark

08.03.2017
23:22:44

Работал кто с ExceptionListener?

Sergey

08.03.2017
23:23:59

Работал кто с ExceptionListener?

было дело

Big_Shark

08.03.2017
23:24:17

было дело

Там же можно сразу 2 лисенера повешать?

@fes0r насколько я понимаю все это вешается вот так tags: - { name: kernel.event_listener, event: kernel.exception } ?

Sergey

08.03.2017
23:24:51

Там же можно сразу 2 лисенера повешать?

ну тип того, но ты можешь прервать вызовы дальнейшие обработчиков

ну тип stopPropogation

@fes0r насколько я понимаю все это вешается вот так tags: - { name: kernel.event_listener, event: kernel.exception } ?

да

Big_Shark

08.03.2017
23:26:20

да

Смотри, у меня в первом есть такая штука if ($exception instanceof EntityNotFoundException) { throw new NotFoundHttpException($exception->getMessage(), $exception); } Но во второй лисенер ничего не приходит, с разу показывается страница с ошибкой

Sergey

08.03.2017
23:28:14

а не. на этом этапе уже не зафариться ивент

Google

Sergey

08.03.2017
23:28:32

ну мол ты уже прошел час X где стоял try/catch который ловил исключение и кидал ивент

Big_Shark

08.03.2017
23:28:36

а не. на этом этапе уже не зафариться ивент

эммм, разве это не странно?

Sergey