Этот баннер — требование Роскомнадзора для исполнения 152 ФЗ.
«На сайте осуществляется обработка файлов cookie, необходимых для работы сайта, а также для анализа использования сайта и улучшения предоставляемых сервисов с использованием метрической программы Яндекс.Метрика. Продолжая использовать сайт, вы даёте согласие с использованием данных технологий».
Политика конфиденциальности
|
|
|
Создавать таблицы динамически или хранить всё в одной?
|
|||
|---|---|---|---|
|
#18+
Нужен совет. Имеется таблица куда записываются данные некоторых устройств. Какая организация лучше(время выборки критично, время записи в меньшей степени): 1) динамическое создание/удаление таблиц для каждого устройства в ходе работы программы или 2) хранение данных всех устройств в одной таблице ? Для извлечения данных используются простые запросы вида: SELECT Id, Time, Speed FROM tracks WHERE Id=123 AND Time BETWEEN 20010101010101 AND 20080101010101 ORDER BY Time По каждому устройству будет добавляться около 3000 строк в день. Количество устройств измеряется сотнями. По другому что лучше: 1) держать 300 таблиц по 300 000 строк в каждой или 2) одну таблицу на 90 000 000(около 10ГБ) ? При использовании множества таблиц в данный момент появляется маленькое неудобство в виде невозможности создания внешнего ключа для целостности данных. Вот и хотелось узнать даст ли способ множества таблиц ощутимый прирост в производительности, хотя с точки зрения логики это менее правильный вариант. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 20.03.2008, 17:39 |
|
||
|
Создавать таблицы динамически или хранить всё в одной?
|
|||
|---|---|---|---|
|
#18+
Можно сделать через разделы: если id это уникальный идентификатор устройства, то делаем так: create table dev ( id int not null, date date, data some_data_type); create table dev1 (check (id = 1)) INHERITS (dev); create table dev2 (check (id = 2)) INHERITS (dev); ... create table devN (check (id = N)) INHERITS (dev); далее создать индекс по полю id для каждого наследника. Теперь создадим функцию dev_insert_trigger() и весим триггер на мастер таблицу CREATE TRIGGER insert_dev BEFORE INSERT ON dev FOR EACH ROW EXECUTE PROCEDURE dev_insert_trigger(); create or replace function dev_insert_trigger() returns trigger as $$ begin if (new.id = 1 ) then insert into dev1 values (new.*); elsif (new.id = 2 ) then insert into dev2 values (new.*); ... else raise exception 'device with id does not exist! fix the server side logic!'; end if; return null; end; $$ language plpgsql; Недостаток такого способа только в том что если появляется новое устройство то надо добавить дополнительную child table devN и исправить функцию dev_insert_trigger(). Зато появляются очевидные преимущества: производительность запросов и обновления данных благодаря использованию data partitioning. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.03.2008, 09:16 |
|
||
|
|

start [/forum/topic.php?fid=53&msg=35204328&tid=2004510]: |
0ms |
get settings: |
9ms |
get forum list: |
15ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
40ms |
get topic data: |
8ms |
get forum data: |
2ms |
get page messages: |
38ms |
get tp. blocked users: |
1ms |
| others: | 226ms |
| total: | 345ms |

| 0 / 0 |
