#нуавообще https://martinfowler.com/eaaCatalog/singleTableInheritance.html

ну она тут явно не при чём)

ну, если кому-то норм, что в мире существует оружие и оно может убить, но пока не стреляет в твою сторону, то ок а я вообще пацифист

а потом люди говорят, что у нас комьюнити токсичное. Лёгким движением руки User превращается в Company, что б не копипастить...

легчайшим)

как бы вот вариант есть, но он меня смущает https://stackoverflow.com/questions/5938418/how-to-change-and-entity-type-in-doctrine2-cti-inheritance

Ладно, а почему например не написать named constructor в Company, который будет принимать User и копировать данные из одного объекта в другой?

Ну или отдельный сервис

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

в общем то я так понимаю это было хреновое решение так сделать? вариант переделать через Join? (Company: user_id ......)

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

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

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

челы супер странные, а как же fail fast ?hm

челы супер странные, а как же fail fast ?hm

вот о том и речь

Ну в прод режиме можно и не фаст

Ладно, а почему например не написать named constructor в Company, который будет принимать User и копировать данные из одного объекта в другой?

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

Ну в прод режиме можно и не фаст

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

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

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

та в том то суть что к этому ресурсу может быть привязано что то,

челы супер странные, а как же fail fast ?hm

и так сойдет)

та в том то суть что к этому ресурсу может быть привязано что то,

Эм, ты точно понимаешь, что ты хочешь? К примеру у тебя есть комент m2o User. Что должно произойти, когда тип объекта поменяется?

поставил roadrunner на сервер

обстрелял артилерией artillery quick --count 2000 -n 2

Summary report @ 19:43:11(+0300) 2018-10-16 Scenarios launched: 2000 Scenarios completed: 2000 Requests completed: 4000 RPS sent: 98.77 Request latency: min: 48.6 max: 2045.8 median: 94.3 p95: 676.1 p99: 1562.5 Scenario counts: 0: 2000 (100%) Codes: 401: 4000

а без оного?)

++ интересно в сравнении

ща

Эм, ты точно понимаешь, что ты хочешь? К примеру у тебя есть комент m2o User. Что должно произойти, когда тип объекта поменяется?

если тип объекта поменяется и User станет Company, то ничего не произойдет, потому что в таблице Company и User ассоциации постоины на основании ID

пых задыхается, цпу почти 100% каждый, c RR там около 25-35%

Summary report @ 19:47:55(+0300) 2018-10-16 RPS sent: 98.84 Request latency: min: 81.4 max: 1190.9 median: 133.7 p95: 346.3 p99: 484.6 Scenario counts: 0: 2000 (100%) Codes: 401: 4000 прод на "/" ===== Summary report @ 19:49:13(+0300) 2018-10-16 Scenarios launched: 2000 Scenarios completed: 2000 Requests completed: 4000 RPS sent: 98.79 Request latency: min: 45.3 max: 1109.1 median: 89.3 p95: 110.2 p99: 112.7 Scenario counts: 0: 2000 (100%) Codes: 401: 4000 прод на RR ":8080/"

чо-т мне кажется там не STI должно быть, а обычный m2o

http://www.techempower.com/benchmarks/

первый обычный, второй с раннером, 4 воркера

я один нахожу эту статистику странной, либо я как то не верно её почитал через CTRL+F PHP

получается симфони медленнее пхп5

а пхп5 быстрее пхп7

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

весь смысл синтетических тестов в одной таблице

привет всем ребят, какой способ записи/чтения для относительно небольших объемов данных наиболее быстр? по вашему личному опыту подойдут как и субд разные, так и что-то иное посоветовали redis, так как аптайм будет огромный, но не знаю, есть ли смысл

Хорошо сформулированные требования)

В файлы пиши

Апйтам не имеет значения

для редиса? и не имеет?)

Я про файлы

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

Небольшие объёмы быстро читаются и пишутся

для редиса? и не имеет?)

не хватает характера данных, требований к скорости записи\чтения и т.д.

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

Относительно небольшие объёмы)

привет всем ребят, какой способ записи/чтения для относительно небольших объемов данных наиболее быстр? по вашему личному опыту подойдут как и субд разные, так и что-то иное посоветовали redis, так как аптайм будет огромный, но не знаю, есть ли смысл

Относительно чего?

Из вопроса ясно лишь, что надо читать и писать

Файлы подходят

максимум - 250 000 записей, в сжатом виде - строка символов на 40

каждая запись

максимум - 250 000 записей, в сжатом виде - строка символов на 40

За секунду? За сутки? За все время?

Что такое сжатый вид?

Кто сжимать будет?

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

Не будет ли сжатие узким местом?

но это - максимальный объём в среднем от 5 до 10к таких строк будет, а не 250000

Их надо каждый раз обновлять по какому-то принципу или дописывать?

Раз в 5 минут записать в среднем 400 килобайт, так? Как потом надо эти данные читать? Какой доступ? Просто прочитать все, что есть или надо как-то отобрать?

Бля)

Короч)

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

почитай что мне ответили) так что тебе ещё повезло

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

Вопроса нету

Пиши в файлы

Или в редис

Или в мемкеш

Или в мускул

Или ещё куда угодно, только выясни как читать тебе их надо

И чем тебе вообще любая база не подошла?

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

если нет разницы и нет вопроса - возьму mysql

Прекрасное решение.

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

"читать быстро" - это тип сильно зависит от структуры которую ты выберешь. Если у тебя там выборки по ключам - то типа срать вообще.

+ всегда можно скейлить чтение горизонтально

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

И что делает ему "медленно"

тоже самое, что, наверное, и в вашем быстрее по сравнению с остальными способами

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

тоже самое, что, наверное, и в вашем быстрее по сравнению с остальными способами

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

Какие требования к скорости чтения?

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

пиши в массив

пиши в массив

+

Самое быстрое решение

тут всегда всё как обычно :) хорошо, выбрал mysql - с ним и буду работать уткнусь в то, что "хотелось бы побыстрее", - поищу

вряд ли в обозримом будущем уткнёшься в это)

Уже лучше))

а когда уткнёшься, посмотри тип inmemory)

Парни, такой вопрос

в бд храниться картинка ( MS SQL ), тип данных image

уже хорошо

при этом есть апи, которое получает данные с клиента

уже хорошо

symfony way

и в этих данных, эта картинка

как сделать так, чтобы эту картинку можно было вывести в качесте img тега, etc...

Тег img в апи - это хорошо

Тег img в апи - это хорошо

...

base64?

хз, похоже на то

мне кажется это был ответ на твой вопрос