ну кто в цепочке твоих микросервисов будет первым?

Если так, то будет просто агрегатор который так же соберёт все что нужно и вернёт тебе своё содержимое, в данном случае это будет страница с многими компонентами

давай мы упростим до простого кейса когда нам ок что каждый микросервис умеет UI

Если так, то будет просто агрегатор который так же соберёт все что нужно и вернёт тебе своё содержимое, в данном случае это будет страница с многими компонентами

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

Да, как то так

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

кто будет в начале? например мы попадаем на UI компонент.... ну например - смотрим свой профиль

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

Но да, если иметь связь один к одному то тут да

Смысла нет

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

Таки да)

Кто делал фейсбук бота? Юзаю https://github.com/pimax/fb-messenger-php Никак не получается получить ответ. Подписка на вебхук оформлена. Запросы доходят на сервер, но ответ не приходит.

Хочу поинтересоваться: как лучше хранить статус пользователя в БД: integer(1, 2, 3 ....) vs string(enabled, disabled, banned) ?

Хочу поинтересоваться: как лучше хранить статус пользователя в БД: integer(1, 2, 3 ....) vs string(enabled, disabled, banned) ?

стринг

инты)

перечисления)

не, только не enum

это базу взорвет

базу взрывают "справочные" таблицы) а перечисления - схера ли?)

попробуй добавить новое значение в enum на табличке большой

о какой базе речь?

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

инты)

почему инты?

стринги!

в чём преимущества строк и недостаток интов?)

стринги у барышень

инт

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

Ребята, кто написал инт\стринг - можно аргументировать плз

интересно мнение

вау) решающий фактор для "большой базы" - удобствопросмотра :) а как индексы по строкам делать - похер)

вау) решающий фактор для "большой базы" - удобствопросмотра :) а как индексы по строкам делать - похер)

Большая база - это рост в течениее нескольких лет до 100к юзеров * на моем проекте*

попробуй добавить новое значение в enum на табличке большой

мм.... типа новое значение добавить?*

Ну типа новый чёйс)

Почему-то на "большой базе" это сложно)

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

может можно и проще

угу, и делаем это на супер базе mysql с нетранзакционными DDL :)

ну допустим у нас нормальная субд

Ну я там за базу выше спросил, тишина)

постгрес например ;)

ну типа "для постгреса енум ок, а для мускуля нет" - уже заставляет задуматься, а нужно ли оно ;)

Ну я там за базу выше спросил, тишина)

MySQL база на данный момент

Для мускуля много чего не ок) но юзают же)

ну типа "для постгреса енум ок, а для мускуля нет" - уже заставляет задуматься, а нужно ли оно ;)

задуматься нужен ли мускуль?)

или о чем?

задуматься, нужен ли енум ;)

Ну он сильно лучше строк :)

задуматься, нужен ли енум ;)

если у тебя мускуль - можно задуматься. Если нужна портируемость - можно задуматься. А если у тебя постгрес - нафига?

На "больших базах")

ну, у нас же приложение, наверно... а ему глубоко пофиг - у тебя из базы придет енумное 'Mrs' или 3 ;)

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

зачем так сложно?

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

что у enum, что у инта

И так, все-таки, есть какие-то доводы за или против стрингов\интов?

вот вот... по этому инт - вполне себе решение... а на нормальных базах можно констрейнт навесить

енум не юзаем

и в случае чего на внешний ключ спрыгнуть легко

Стринг точно в мусорку) енам или инт - другой вопрос

вот вот... по этому инт - вполне себе решение... а на нормальных базах можно констрейнт навесить

А в какой ситации можно констрейнт на поле статуса накидовать?Оо

в любой, если у тебя 0 1 2 там только может быть, навешиваешь, на >=0 и <=2 :)

Стринг точно в мусорку) енам или инт - другой вопрос

может инт более гибкий? Ну типа, меньше гемора добавить-новые\удалить-старые статусы

в любой, если у тебя 0 1 2 там только может быть, навешиваешь, на >=0 и <=2 :)

ну, данное поведение я как раз на уровне приложения делаю

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

может инт более гибкий? Ну типа, меньше гемора добавить-новые\удалить-старые статусы

вкусовщина, как по мне

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

ERROR: S client not available

там с точки зрения производительности разница если и есть, то где-то на уровне погрешности. Чего про строки не сказать

в любой, если у тебя 0 1 2 там только может быть, навешиваешь, на >=0 и <=2 :)

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

ну да, а это проблема разве?

ну да, а это проблема разве?

Хз чесн говоря))

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

зато можно красиво делать репортики через SQL

без CASE

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

поэтому "большая база" всегда было в ковычках) у кого-то и 5 гигов фултекстов суммарно - омфг размеры

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

Т.е., в таком случае лучше взять инт (на перспективу аля), а статусы задокументировать прост

если не енам, то очевидно инт)

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

если не енам, то очевидно инт)

и не забудь добавить функцию которая будет в sql инт в строку преобразовывать)) удобно ж

ну я сам енамы юзаю) мне ок)

а я строки) и мне ок) ну инты тоже и енамы... короч как пойдет

для больших таблиц используем int. от enum отказались из-за проблем при изменении набора статусов. хотя по факту они не так часто и меняются

в маленьких таблицах - строки

а я строки) и мне ок) ну инты тоже и енамы... короч как пойдет

зачем те строки-то?)

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

для больших таблиц используем int. от enum отказались из-за проблем при изменении набора статусов. хотя по факту они не так часто и меняются

а как давно проблема была то? а то вроде как в mysql чето фиксили с этим

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

но с оговорками)

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

Про постгрес ;) Comparisons involving an added enum value will sometimes be slower than comparisons involving only original members of the enum type. This will usually only occur if BEFORE or AFTER is used to set the new value's sort position somewhere other than at the end of the list. However, sometimes it will happen even though the new value is added at the end (this occurs if the OID counter “wrapped around” since the original creation of the enum type). The slowdown is usually insignificant; but if it matters, optimal performance can be regained by dropping and recreating the enum type, or by dumping and reloading the database.

Про постгрес ;) Comparisons involving an added enum value will sometimes be slower than comparisons involving only original members of the enum type. This will usually only occur if BEFORE or AFTER is used to set the new value's sort position somewhere other than at the end of the list. However, sometimes it will happen even though the new value is added at the end (this occurs if the OID counter “wrapped around” since the original creation of the enum type). The slowdown is usually insignificant; but if it matters, optimal performance can be regained by dropping and recreating the enum type, or by dumping and reloading the database.

много букв

те перевести? ;)

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

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

те перевести? ;)

да я прочитал, мне не понятно к чему ты это привел. Там же написано в конце - просто пересоздайте тип.

и то для большинства это не особо критично

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

не уверен - проверь)

угу, "проверь, авось продакшн не завалится" ;)

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