|
а как вы храните селекторы в БД?
|
|||
---|---|---|---|
#18+
Я так понимаю, эту тему полностью отдали на откуп фреймворкам, потому что в гугле что-то совсем вакуум... В общем, тут такая дилемма - как именно хранить нулевое значение (которое самым первым идёт) ? Если его хранить в виде NULL, то тогда JOIN пропустит эти строки (проверено), надо делать LEFT JOIN, а он уже требует побольше ресурсов, что нежелательно. Поэтому я храню в виде 0, НО, например, в таблице банков нет банка с ID=0. Т.е. тоже не очень удобно - надо его создавать. А ещё, при всём при этом, FK должен нормально работать, т.е. всё должно совпадать иначе он не создастся. Как у вас это всё реализовано? ... |
|||
:
Нравится:
Не нравится:
|
|||
06.04.2018, 00:11 |
|
а как вы храните селекторы в БД?
|
|||
---|---|---|---|
#18+
Зачем вам вообще пхп? Он ресурсов много требует. Пишите на ассемблере. И СУБД вам не нужна. Используйте файлы, они на много быстрее. ... |
|||
:
Нравится:
Не нравится:
|
|||
06.04.2018, 07:28 |
|
а как вы храните селекторы в БД?
|
|||
---|---|---|---|
#18+
tip78как именно хранить нулевое значение (которое самым первым идёт) ? Если его хранить в виде NULLЗачем фантазировать? NULL - нет значения, 0 - значение равно нулю. tip78тогда JOIN пропустит эти строки (проверено), надо делать LEFT JOIN, а он уже требует побольше ресурсовБольше чем в случае с "0" в качестве значения? ... |
|||
:
Нравится:
Не нравится:
|
|||
06.04.2018, 08:34 |
|
а как вы храните селекторы в БД?
|
|||
---|---|---|---|
#18+
vkletip78тогда JOIN пропустит эти строки (проверено), надо делать LEFT JOIN, а он уже требует побольше ресурсовБольше чем в случае с "0" в качестве значения? эмм, вообще-то я упустил момент, что подключаемая таблица мелкая, так что LEFT JOIN мгновенно отрабатывает. Вот так вот: Код: sql 1. 2. 3.
автор1. nested loop (пробег по одной таблице, потом по другой). Самый предпочтительный на мгновенных запросах, когда надо отдать быстро первые значения. ПЛОХ для больших объёмов данных. НЕ УМЕЕТ FULL OUTER JOIN! -- надо смотреть на work_mem (сколько памяти может занять 1 воркер), если таблица захешируется в 100мг, а воркеру дано 30мб, то будут тормоза. -- Надо добавить памяти и тогда оптимизатор выберет этот вариант 2. hash join: хеширование маленькой таблицы, а потом подстановка её значений в большую (таблица может не поместиться в памяти) не нужен индекс, может быть использован для FULL OUTER JOIN 3. merge join (любимый у Ивана Фролкова) - сливаем 2 отсортированных таблицы, проверяем условия и формируем строку ни к чему не требователен. Умеет OUTER/FULL/LEFT/RIGHT JOIN. требует отсортированные списки (либо индекс, либо сортировка) ... |
|||
:
Нравится:
Не нравится:
|
|||
06.04.2018, 13:48 |
|
а как вы храните селекторы в БД?
|
|||
---|---|---|---|
#18+
tip78, Вероятно, вопрос касается в бОльшей степени конкретной СУБД, нежели PHP/Perl/Python и есть смысл перенести этот топик в профильный форум. В какой? ... |
|||
:
Нравится:
Не нравится:
|
|||
06.04.2018, 15:07 |
|
|
start [/forum/topic.php?fid=23&tid=1460318]: |
0ms |
get settings: |
7ms |
get forum list: |
12ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
38ms |
get topic data: |
13ms |
get forum data: |
3ms |
get page messages: |
47ms |
get tp. blocked users: |
2ms |
others: | 12ms |
total: | 140ms |
0 / 0 |