|
|
|
Большое количество колонок
|
|||
|---|---|---|---|
|
#18+
К вопросу о сомнительном дизайне. Есть два варианта для таблички: 1. Таблица на 5 полей и 150 миллионов записей. 2. Таблица на 150 полей и 1 миллион записей. Какой вариант позволит добиться максимальной скорости выборки? Если отбор будет происходить по индексируемым полям, и дифференциация значений в них (особенно в первом варианте) не очень большая? Интуитивно понимаю что второй вариант быстрее. И если это так, то как объяснить программисту, что те 150 полей которые ему предстоит описать в маппере - это не бред похмельный, а ради дела праведного? :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.10.2017, 11:26 |
|
||
|
Большое количество колонок
|
|||
|---|---|---|---|
|
#18+
G@rry_, Есть такой формат ISO8583, в частности карточный процессинг его использует. Там пакет содержит до 128 полей. Дык вот, когда писал обработчик в 2003 году, то тоже сначала сделал 3 полей — типа по науке, EAV и всё такое. И на первом же запросе, типа: для транзакции у которой (f012=A, f013=B, f025=C, f030=D, f32=E) надо найти пару (соответствующие поля одинаковые), но чтобы поле f042 отличалось — плюнул и переделал на таблицу со 135 полями. Так что пусть программист не ноет — ему запросы 1 раз сделать, а систему потом в продукции поддерживать — годы (тьфу-тьфу)! ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.10.2017, 11:46 |
|
||
|
Большое количество колонок
|
|||
|---|---|---|---|
|
#18+
G@rry_, я бы поискал третий вариант. может вынести из второго варианта какие-то неизменяемые поля, по которым не будет поиска в hstore/json/jsonb. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.10.2017, 12:48 |
|
||
|
Большое количество колонок
|
|||
|---|---|---|---|
|
#18+
Alexius, И что мне это даст кроме тормозов на выборке? У меня данные вообще не меняются. Просто добавляются и выбираются для отчетов. Количество колонок фиксированное, циферьки там, потребности в XML, слава богу, нет. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.10.2017, 13:34 |
|
||
|
Большое количество колонок
|
|||
|---|---|---|---|
|
#18+
G@rry_, я же не знаю что у вас за данные. может там 90% колонок всегда null для каждой строки или колонки вида column1..columnN которые в массив логичнее запихнуть. или много колонок, которые читаются пару раз в год, а остальное время только мешают. и может быть удобнее работать с денормализованными данными, чем с 150 полями. +есть физическое ограничение на число полей в таблице (строка без toast'ов должна целиком помещаться на одной странице), вдруг через какое-то время понадобится не 150, а 1000 колонок. тормоза могут быть в варианте с 150 колонками, когда строки очень широкие и в toast ничего не выносится и нужно будет все колонки читать с диска, даже если нам нужна одна колонка в запросе. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.10.2017, 14:00 |
|
||
|
|
start [/forum/topic.php?fid=53&fpage=66&tid=1996198]: |
0ms |
get settings: |
10ms |
get forum list: |
12ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
55ms |
get topic data: |
9ms |
get forum data: |
2ms |
get page messages: |
44ms |
get tp. blocked users: |
2ms |
| others: | 15ms |
| total: | 155ms |
| 0 / 0 |
