нуууууу такое

я жду доктрину 3

там выпиливают овердохрена всего

щас вот поменяли полностью то как работают метаданные по классам

должны стать в разы шустрее, там с ассоц массивчиков все на ОО переделали

чтобы в опкеш влазило

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

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

это догадки без каких-либо подтверждений)

Propel для Doctrine вообще не конкурент по-моему.

заговорили за пропел, вспомнил бигшарка

BigShark*

а вот и он)

Он контрибьютер?

?

как это работает

что именно?)

привет Макс)

добавление людей)

Он контрибьютер?

Был

как это работает

Магия php)

Фабьеен

привет Макс)

Нихао

:(

Был

Привет ?

чет не вышло, ладно, потопаю спать

добавление людей)

Заходим в канал, и там инвайт мембер

но тебя ж не заинвайтили

а ты сам пришел

о.о

да эт я ему линк дал)

нет, это магия

Мне кинули ссылку, и я присоединился к каналу

ок, это магия

а ты еще симфони юзаешь хоть?

ну да, 3 или 3.1 чтото такое

? 3.2

но там смесь всего и вся

https://www.youtube.com/watch?v=VB_U5R2_FUs

http://stackoverflow.com/a/15630665

Ну это и есть первый вариант с 32 таблицами отношений.

А что везде отношения многие ко многим?

ну я ж поэтому и дал схему )

ну хорошо, будет не 32, а пусть в реальной ситуации будет 20, для 5 модулей, но модулей то ведь не 5 будет, а может быть 20-30-40... в итоге это разростается в тупой контроль за добавлением новых отношений.

а зачем отдельные emails, companies? че просто не писать name?

всмысле? потому что у одной персоны может быть несколько email, адресов, и т.п.

То же самое и у компаний, и т.д.

через запятую их запиши в поле)

эммм... а искать потом тоже через запятую? )

смотря че требуется и какие будут выборки

это во-первых, во-вторых - адреса там больше полей, тоже через запятую не пойдет

Кросс-поиск обязателен

ну адреса отдельная таблица эт ок

Так то же самое касается и телефонов и прочего.

окей. так а в чем проблема то?

тебе нужны связи company -> email -> user?

Есть проблема выбора архитектуры: - есть вариант стандартный в доктрине: через отдельную таблицу для каждого отношения, и в этом случае будет дохреналион таблиц; - второй вариант, это как в eloquent orm реализованы polymorph relationships.

Company-Email-User - нет, не нужны.

нужна Company -> Email (с дополнительными полями), User -> Email (с дополнительными полями)...

ок, тогда можешь упростить и оставить только person person_email company company_email

Есть проблема выбора архитектуры: - есть вариант стандартный в доктрине: через отдельную таблицу для каждого отношения, и в этом случае будет дохреналион таблиц; - второй вариант, это как в eloquent orm реализованы polymorph relationships.

дохреллион таблиц только в базе будет, для доктрины это прозрачно как бы

блин, это я и описал же :) И в этом случае будет много таблиц

у тебя будет только Person и Email

никаких PersonEmail для связи

ERROR: S client not available

Эммм... можно было бы, но... в этом случае нет возможности проверки уникальности email и дубликаты

и еще вопрос. как ты будешь следить за мертвыми данными?

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

или вообще поменяли эмейл А, а его еще юзает компания

Вот во втором случае - это элементарно проверить, в первом - email -останется.

ну это вообще окей что юзер меняет себе эмейл, а он поменяется у компании?

Вот во втором случае - это элементарно проверить, в первом - email -останется.

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

Хороший кейс.

Я бы даже сказал очень хороший кейс

Что-то меня смущало в этих подходах, поэтому я и на пиздец-долго завис с этой темой.

секунду, надо визуализировать себе

Получается чистый CTI в этом случае

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

всеравно конечно остается дофига таблиц, но не так страшно.

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

Сереж, я не совсем врубаюсь как использовать DTO (

model first и вся херня

при чем тут DTO вообще?

у тебя тут доменная область в чистом виде

Эм, видимо ошибся в терминологии...

А как это правильно называется? )

По не нашему )

почитай эванса, у него на эту тему аж 2 книги красная и синяя

Ага, нашел... Уйду читать щас...

Domain-Driven-Design (это синяя) - а еще какая?

https://www.amazon.com/Implementing-Domain-Driven-Design-Vaughn-Vernon/dp/0321834577 https://www.amazon.co.uk/Domain-driven-Design-Tackling-Complexity-Software/dp/0321125215

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

еще в json можно запихнуть

мускуль умеет с ним работать

и postgre

через запятую не выйдет, в json только

Ну в Джексон норм