ReSQL.ru
     
powered by simpleCommunicator - 2.0.60     © 2026 Programmizd 02
Мобильная версия    Контакт    Правила    FAQ    Помощь
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Доб. в избранное | Игнор. тему | Прикреп. тему | Пометить прочит. / непрочит. | Фильтр
Форумы / Проектирование БД [игнор отключен] [закрыт для гостей] / Что лучше - одна большая таблица или много маленьких?
12 сообщений из 12, страница 1 из 1
Что лучше - одна большая таблица или много маленьких?
    #32632207
T0nic
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
T0nic
Гость
Суть проблемы такова:
есть таблица MB(ID,PHONE,Name, Surname,....,PROFIT,PARENT_ID),
т.е. иерархическая структура. Но дело ни в этом.
Каждый месяц нужно будет заполнять поле PROFIT для каждого ID, причем количество записей будет расти. К тому же нужно хранить данные за предыдущие месяцы. Пока на ум пришло 2 способа:

1) каждый месяц программно создавать новые таблицы типа
FEE082004(ID,PROFIT)
FEE092004(ID,PROFIT)
...
и с ними работать.

2) Создать одну таблицу
FEE(ID,DATE,PROFIT) c ключем (ID,DATE).

Второй способ вроде проще, но ведь таблица будет очень быстро расти, т.е.
если в первом месяце было n записей, то во втором 2*n+k (k - прибавилось за месяц), в третьем - 3*n+2*k+k2...
...
Рейтинг: 0 / 0
02.08.2004, 21:15
| Ответить | Цитировать | Написать  
Что лучше - одна большая таблица или много маленьких?
    #32632245
Фотография Cat2
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Cat2
Модератор форума
Ни в коем случае приложение не должно создавать в базе новых постоянных таблиц!
...
Рейтинг: 0 / 0
02.08.2004, 23:07
| Ответить | Цитировать | Написать  
Что лучше - одна большая таблица или много маленьких?
    #32632422
EvgK
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
EvgK
Гость
Возможен промежуточный вариант: допустим наиболее часто используемыми у нас являются последние 3 месяца, тогда эти три месяца хранить в одной таблице (оперативные данные), а все остальные данные хранить в таблице архива и периодически переносить данные в архив.
В этом случае:
1. Поскольку архив будет обновляться редко, а в основном из него будут извлекаться данные, то можно организовать индексы соответствующим образом (например кластерными индексами в MsSQL)
2. В таблице оперативных данных будет не так много записей
...
Рейтинг: 0 / 0
03.08.2004, 09:25
| Ответить | Цитировать | Написать  
Что лучше - одна большая таблица или много маленьких?
    #32632476
funikovyuri
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
funikovyuri
Участник
T0nic

Если очень нужно то
- создаете 2 (или более) таблиц - например
FEE_CUR(ID,DATE,PROFIT) и
FEE_ARC(ID,DATE,PROFIT)

в первой все записи за текущий месяц, во второй все остальные

- затем создаете Partitioned View (если у вас MS SQL2000)
...
Рейтинг: 0 / 0
03.08.2004, 09:49
| Ответить | Цитировать | Написать  
Что лучше - одна большая таблица или много маленьких?
    #32632481
funikovyuri
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
funikovyuri
Участник
T0nic

Если очень нужно то
- создаете 2 (или более) таблиц - например
FEE_CUR(ID,DATE,PROFIT) и
FEE_ARC(ID,DATE,PROFIT)

в первой все записи за текущий месяц, во второй все остальные

- затем создаете Partitioned View (если у вас MS SQL2000)
...
Рейтинг: 0 / 0
03.08.2004, 09:51
| Ответить | Цитировать | Написать  
Что лучше - одна большая таблица или много маленьких?
    #32632544
gardenman
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
gardenman
Участник
Одна большая таблица (при условии нормализации) гораздо выгоднее чем много мелких, тем более постоянно создаваемых. Меньше кода надо писать. А IO будет примерно одним и тем же. Проще большую таблицу и ее индексы разнести по дискам, если уж так сильно не устраивает производительность.
Или опять же выделить кэши специально для индексов/данных именно этой таблицы. Пересмотреть индексы - по возможности уменьшить количество индексов за счет создания составных индексов.
...
Рейтинг: 0 / 0
03.08.2004, 10:14
| Ответить | Цитировать | Написать  
Что лучше - одна большая таблица или много маленьких?
    #32637234
dph
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
dph
Гость
Ну, если на MSSQL делать, то рекомендую одну большую таблицу и indexed view для "актуальных" значений...
Тогда и скорость будет очень высокая и проблем с архивацией никаких....
...
Рейтинг: 0 / 0
05.08.2004, 15:53
| Ответить | Цитировать | Написать  
Что лучше - одна большая таблица или много маленьких?
    #32638874
Shr
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Shr
Участник
Наколько я понял, почти все поля таблицы являются постоянными, изменяется во времени только профит?
Тогда, имхо, лучше его вынести в отдельную таблицу с датой cмены значения, т.е:

create table MB(ID,PHONE,Name, Surname,....,PARENT_ID)
create table MB_PROFIT_HISTORY(
ID,
CDate,
PROFIT, -- новое значение, действует с CDate
primary key (id, cdate)
)
...
Рейтинг: 0 / 0
06.08.2004, 15:19
| Ответить | Цитировать | Написать  
Что лучше - одна большая таблица или много маленьких?
    #32638887
Shr
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Shr
Участник
И еще. Не так давно у меня была мысль хранить в истории изменений атрибута не только дату начала действия, но и дату конца - либо null, если это последняя дата. По идее, такой подход требует дополнительных вложений в поддержку автоматического заполнения даты окончания действия (которое несложно реализовать триггерами) - но дает выигрыш в выборке значения на дату, т.е. не требует использования подзапроса:
select value
from t
where
id = :id and
cdate = (
select max(cdate) where id = :id and cdate < :to_date
)

так вот. на практике такой подход я не реализовывал и хочу спросить, не пробовал ли кто сделать такое и стоит ли овчинка выделки?
...
Рейтинг: 0 / 0
06.08.2004, 15:27
| Ответить | Цитировать | Написать  
Что лучше - одна большая таблица или много маленьких?
    #32638907
Shr
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Shr
Участник
Сорри, не договорил. Вместо подзапроса можно использовать:
select value
from t
where
id = :id and
((:to_date between cdate and edate) or (:to_date >= cdate and edate is null))

В общем, интересно, какой именно из запросов легче для выполнения - и насколько это зависит от оптимизатора СУБД?
...
Рейтинг: 0 / 0
06.08.2004, 15:33
| Ответить | Цитировать | Написать  
Что лучше - одна большая таблица или много маленьких?
    #32638913
locky
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
locky
Участник
>Не так давно у меня была мысль хранить в истории изменений атрибута не только дату начала действия, но и дату конца - либо null, если это последняя дата.
я так делаю, только вместо null пишу условный "конец времен" - 21000101
тогда не надо писать так
Код: plaintext
1.
 select * from SomeTable where datefrom <= @date and (@date <= dateto or dateto is null)
а можно просто
Код: plaintext
1.
 select * from SomeTable where datefrom <= @date and @date <= dateto
аналогично с датой начала
...
Рейтинг: 0 / 0
06.08.2004, 15:34
| Ответить | Цитировать | Написать  
Что лучше - одна большая таблица или много маленьких?
    #32638976
Shr
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Shr
Участник
Мда, было бы излишне оптимистично считать, что какой-бы то ни было нынешний проект через сто лет еще будет работать :-)
...
Рейтинг: 0 / 0
06.08.2004, 16:04
| Ответить | Цитировать | Написать  
12 сообщений из 12, страница 1 из 1
Форумы / Проектирование БД [игнор отключен] [закрыт для гостей] / Что лучше - одна большая таблица или много маленьких?
Найденые пользователи ...
Разблокировать пользователей ...
Читали тему (0):
Читали форум (0):
Пользователи онлайн (0):
x
x
Закрыть


Просмотр
0 / 0
Close
Debug Console [Select Text]