СС
а для здесь вообще Compute Scalar? чтобы сравнить кортежи(пару)?
Size: a a a
2021 June 09
A
Полагаю, что в режиме 140 наступит стабильность планов.
АР
Я же вам уже написал, что там вычисляется.
СС
понял, спасибо!
СС
в режиме 140 ничего не меняется, что логично из объяснения Александра
A
Отлично
2021 June 10
ГС
нормально ли записывать данные через запятую, вместо того чтобы на каждый элемент выделять строку?
1056; 13,14,19,17
1056; 13,14,19,17
ГС
есть недостатки такого решения?
O
Нарушение реляционной логики. будет геморрой потом с поиском значений. Чтобы найти потом нужный banned_day_hour никакой индекс не поможет, будет фуллскан с поиском по LIKE '%14%'
ГС
а если нет нужды искать такое
O
Зачем вы данные храните, если не будете к ним обращаться? Как потом извлечь значение из banned_day_hours? В целом это совершенно неправильный подход. Это реляционная СУБД, в одной ячейке одно значение.
ГС
я обращаюсь. но это всегда select banned_day_h from conf_id where conf_id=123
O
А потом вы парсите строку?
ГС
нет, получаю список. но в ином случае придется парсить
O
Ну короче, с точки зрения реляционных БД это не верно. Жизнь научила меня, что такие вещи могут потом придти в самый неудачный момент и трахнуть тебя самым подлым образом. Так что я не советую. Что вы теряете в случае с текущим дизайном?
ГС
ничего. просто занимаюсь оптимизацией бд
O
ну вот третья нормальная форма - это пример оптимизации. Придерживайтесь её, не прогадаете.
Ж
Datagrip
Л
А Вы пробовали dbForge?
O
Вообще там Сергей сказал и я подтверждаю, это SentryOne Plan Explorer.