Не, его ща пол года так и не загрузили работой)

Он в общем ютубчик смотрел)

дба увидел Clipper и сломался?

Некрофилия какая-то. Центуру бы ещё помянули)

Некрофилия какая-то. Центуру бы ещё помянули)

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

и это было года два назад максимум, если что

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

Ну и правильно. Это ж жесть. Хотя чего это я) В моей шаражке был Pascal и VB6)) Благо БД делали на MS SQL хотя бы)

Ну и правильно. Это ж жесть. Хотя чего это я) В моей шаражке был Pascal и VB6)) Благо БД делали на MS SQL хотя бы)

а когда это было?) в моем вузе был раньше тоже паскаль и vb6, и вроде firebird, хотя я уже начинал с плюсов и mysql

а когда это было?) в моем вузе был раньше тоже паскаль и vb6, и вроде firebird, хотя я уже начинал с плюсов и mysql

Да лет 5 назад. Ну и не вуз, а колледж. Вуз я так и не закончил (на заочке учился). Работать надо было.

тогда не повезло - у меня тоже пять лет назад все это было...

Как думаете можно используя CQRS + Event Sourcing полностью отказаться от реляцийниих БД и перейти на NoSQL?

Как думаете можно используя CQRS + Event Sourcing полностью отказаться от реляцийниих БД и перейти на NoSQL?

А зачем там реляционная субд?)

Твм ключ/значение) стримы можно хранить без проблем в любой)

я думаю, речь про документную скорее

монга и прочие

Монга чет не зашла(

мне интересно смогу лия отказатся от мускуля и перейти на монгу полностю. например: Будет ли удобно работать з большим скоупом ивентов? Будет ли удобно хранить юзеров и пароли.

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

каждый инструмент создается для своей области

мне интересно смогу лия отказатся от мускуля и перейти на монгу полностю. например: Будет ли удобно работать з большим скоупом ивентов? Будет ли удобно хранить юзеров и пароли.

Нет

Вброшу, но хайп по NoSQL был ошибкой

Это радикально узкоспецифичный инструмент

Вброшу, но хайп по NoSQL был ошибкой

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

Вброшу, но хайп по NoSQL был ошибкой

тоже не согласен. в нево есть свои плюсы

Пофиксил

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

если у тебя есть таблиц 100+ колонок. значит чтото пошло не так))

если у тебя есть таблиц 100+ колонок. значит чтото пошло не так))

это денормализованные данные. Обычно они не маленькие.

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

А откуда у вас денормализованные данные — это лень или обстоятельства?

Я могу ошибаться, но первое встречается гораздо чаще второго

А откуда у вас денормализованные данные — это лень или обстоятельства?

это оптимизация, когда join слишком дорогие, ты от нормализации идешь к денормализации, что бы запросы выполнялись быстрее.

По сути как кэш работает? ?

Ну и опять же, jsonb

Ну и опять же, jsonb

очень конечно удобно работать с jsonb

¯\_(ツ)_/¯

особенно когда по полям, внутри jsonb надо фильтрацию делать

По сути как кэш работает? ?

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

мне интересно смогу лия отказатся от мускуля и перейти на монгу полностю. например: Будет ли удобно работать з большим скоупом ивентов? Будет ли удобно хранить юзеров и пароли.

где связь между пользователями, их паролями и event sourcing'ом,

я ж могу создать CreateUserEvent, и потом по почте найти ивент и юзера в нем

если у тебя нету какого-то индекса, не сможешь

индекс - не в контексте конечного стораджа. А в контексте какого-то kv, который хранит связь между требуемым значением и агрегатом

https://github.com/mmasiukevich/service-bus-demo/blob/master/src/Customer/Services/RegisterCustomerService.php#L58 как-то так. если хранить в jsonb в каком-нить постгресе и искать финальную версию email'а юзера в громадном списке событий - херня выходит

ясно. спасибо

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

Maksim Masiukevich - смотрю твой код, можеш расказать зачем ти хочеш перейти на AmPHP. "Get away from callback hell (change ReactPHP to AmPHP)"

Maksim Masiukevich - смотрю твой код, можеш расказать зачем ти хочеш перейти на AmPHP. "Get away from callback hell (change ReactPHP to AmPHP)"

amphp компактнее

скажем так, вся срань с промисами там изящно спрятана

суть у них одна и таже я верно понял?

суть у них одна и таже я верно понял?

по сути да

ясно) спасибо посмотрю в ету сторону

особенно когда по полям, внутри jsonb надо фильтрацию делать

А в чем проблема?

Хоть индексы добавляй, хоть фильтруй, хоть на лету строй

И все равно быстрее монги

И все равно быстрее монги

пруфы?

пинг

пруфы?

http://tiborsimko.org/postgresql-mongodb-json-select-speed.html http://erthalion.info/2017/12/21/advanced-json-benchmarks/

пинг

все переходим на посгрес все

проще в несколько раз, чем процедурную ооп лапшу

взаимноисключающие параграфы детектед

монга ок для лентяев и любителей apt-get install) если смотреть дальше и больше, начинается развлекуха и её необходимость вызывает вопросы

монга ок для лентяев и любителей apt-get install) если смотреть дальше и больше, начинается развлекуха и её необходимость вызывает вопросы

для любителей yum install уже не подойдет?

для любителей yum install уже не подойдет?

вряд ли0

http://blog.ploeh.dk/2013/01/09/MetadataRoleHint/

товарищ профессор, студент 1-го курса не понимает, паттерн detached metadata с ручным добавлением в контейнер лучше, чем все остальное (т.к. проще, т.е. по KISS ) ?

detached metadata "injecting mapping dictionary from composition root"

у меня инстанцы IBasketCalculator уже имеют зависисмости в конструкторе

т.е. они должны быть в контейнере

как их проще добавить в SimpleInjector ?

Одним из преимуществ использования Event Sourcing пишут о возможности восстановления объекта до нужной точки (состояния). Предположим что я использую Doctrine для работы с БД. И я удалил на каком-то из этапов жизненного цикла заказа колонку с БД в которой был какойто атрибут заказа. Как я смогу создать обект на основе ивента где еще есть информация о колонке? Получается что я теряю цилоснисть объекта. И во время востановлення не будет найден нужна колонка и я получу ошибку. Или я неверно понял возможность востановления?

Одним из преимуществ использования Event Sourcing пишут о возможности восстановления объекта до нужной точки (состояния). Предположим что я использую Doctrine для работы с БД. И я удалил на каком-то из этапов жизненного цикла заказа колонку с БД в которой был какойто атрибут заказа. Как я смогу создать обект на основе ивента где еще есть информация о колонке? Получается что я теряю цилоснисть объекта. И во время востановлення не будет найден нужна колонка и я получу ошибку. Или я неверно понял возможность востановления?

у тебя не хранятся данные в колонках

нет никаких колонок с заказами

у тебя есть максимум 2 таблицы

Одним из преимуществ использования Event Sourcing пишут о возможности восстановления объекта до нужной точки (состояния). Предположим что я использую Doctrine для работы с БД. И я удалил на каком-то из этапов жизненного цикла заказа колонку с БД в которой был какойто атрибут заказа. Как я смогу создать обект на основе ивента где еще есть информация о колонке? Получается что я теряю цилоснисть объекта. И во время востановлення не будет найден нужна колонка и я получу ошибку. Или я неверно понял возможность востановления?

удаление колонки из базы - это как бы не жизненный цикл заказа

Одним из преимуществ использования Event Sourcing пишут о возможности восстановления объекта до нужной точки (состояния). Предположим что я использую Doctrine для работы с БД. И я удалил на каком-то из этапов жизненного цикла заказа колонку с БД в которой был какойто атрибут заказа. Как я смогу создать обект на основе ивента где еще есть информация о колонке? Получается что я теряю цилоснисть объекта. И во время востановлення не будет найден нужна колонка и я получу ошибку. Или я неверно понял возможность востановления?

ты не правильно понял зачем надо event sourcing)

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

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

нет, с ES ты хранишь ивенты

мы храним список событий

и только их

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

а зачем?

а не состояние. состояние - следствие наступления событий

снэпшеты данных построенные по этим ивентам - это скорее как кэш

а не как "храним"

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

если у тебя у сущности по 10-100 событий то можно вообще даже снэпшеты не делать

чтоб потом пройтися по цепочки и получить обект

entity = leftFold(events)

да.. пока сложно идет информация.. нужно еще разбиратся. спасибо

да.. пока сложно идет информация.. нужно еще разбиратся. спасибо

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

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

это не так просто)

да.. пока сложно идет информация.. нужно еще разбиратся. спасибо

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

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

Только NeSQL только хардкор

господа, возвращаясь к уходу от сеттеров

по вашему мнению, корректно ли использовать методы вроде $foo->change($firstName, $lastName, $email, $phone) для штук вроде обработчика формы редактирования (утрированно)?

я бы сделал 2 объекта и на 2 метода разделил)