|
|
|
Маркерный интерфейс
|
|||
|---|---|---|---|
|
#18+
love_bachпросто интересно - если бы ну вот сильно сильно надо было , то как? в идеале, подписываться на события, которые генерит команда. два варианта подписки: 1. постоянная подписка, логика отдельно, хорошо. 2. разовая подписка на изменение, тогда командам хорошо бы иметь свои ид-шники, приемлимое решение суть в том, что команда может генерировать множество событий, ещё команда может вызывать вложенные команды, а вам может понадобится только какое-то конкретное событие. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.10.2019, 23:49 |
|
||
|
Маркерный интерфейс
|
|||
|---|---|---|---|
|
#18+
love_bachlove_bachвынести эту нормализацию из команды? точно! бл*, она еще и в валидаторах, типа если могу - нормализирую. придется и это еще исправить да, отличная идея :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.10.2019, 23:51 |
|
||
|
Маркерный интерфейс
|
|||
|---|---|---|---|
|
#18+
fkthathVosttтогда можно было и отказаться от автоинкремента и просто сделать свой гуид примари Гуид примари для кластерного индекса это не очень хорошо, потому что он не sequential и это сильно тормозит вставку. Тут разве что если генерить последовательные гуиды (в сиквеле есть готовая ф-ия, на клиенте немного сложнее, но вполне решаемо). Но, собственно, пара айдишек на деле совсем не напрягает, тем более у нас эти "внешние" guid-ы почти везде используются только для корней агрегатов. если скорость вставки так критична, то да, норм решение не думаю, что стоит заморачиваться с генерацией последовательных гуидов ) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.10.2019, 23:52 |
|
||
|
Маркерный интерфейс
|
|||
|---|---|---|---|
|
#18+
fkthathVosttтогда можно было и отказаться от автоинкремента и просто сделать свой гуид примари Гуид примари для кластерного индекса это не очень хорошо, потому что он не sequential и это сильно тормозит вставку. Тут разве что если генерить последовательные гуиды (в сиквеле есть готовая ф-ия, на клиенте немного сложнее, но вполне решаемо). Но, собственно, пара айдишек на деле совсем не напрягает, тем более у нас эти "внешние" guid-ы почти везде используются только для корней агрегатов. Можно делать некластерным (primary key nonclustered), проблему со скоростью вставки это вполне решает (но надо смотреть как это отразиться на скорости других запросов). ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 31.10.2019, 09:27 |
|
||
|
Маркерный интерфейс
|
|||
|---|---|---|---|
|
#18+
hVosttне думаю, что стоит заморачиваться с генерацией последовательных гуидов ) На самом деле, это очень просто, у меня где-то даже готовый код валяется для этого. МС-овский гуид (UUID версии 4) - это просто случайные биты (кроме то ли шести то ли семи фиксированных). Достаточно взять "обычный" гуид и часть старших битов заменить на таймстемп. Возможны правда сбои в порядке при одновременной генерации на разных узлах, но если их вероятностью можно пренебречь, то все должно быть ок. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 31.10.2019, 15:28 |
|
||
|
Маркерный интерфейс
|
|||
|---|---|---|---|
|
#18+
fkthat, недавно была дискуссия https://www.sql.ru/forum/1287606/vnyatno-obyasnit-pochemu-klasterizovannyy-indeks-po-guid-huzhe-int я бы всёж не заморачивался с этим до реальных замеров в конкретном кейсе. ну медленнее вставка будет, вопрос насколько? создаёт ли это проблемы с текущей пиковой нагрузкой? а если нужен шардинг, то что? ну и т.д. :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 31.10.2019, 19:12 |
|
||
|
|
start [/forum/topic.php?fid=20&startmsg=39883370&tid=1398741]: |
0ms |
get settings: |
10ms |
get forum list: |
15ms |
check forum access: |
4ms |
check topic access: |
4ms |
track hit: |
130ms |
get topic data: |
9ms |
get forum data: |
3ms |
get page messages: |
37ms |
get tp. blocked users: |
1ms |
| others: | 262ms |
| total: | 475ms |
| 0 / 0 |
