| Форумы
ЧАТ |
Орешник |
|
| Форумы -» | Основная («Начинающим»)/ Базы / WinAPI / Компоненты / Сети / Media / Игры / Corba и COM / KOL / FreePascal / .Net / Прочее / RSDN.ORG |
|
| ||
|
|
Новости |
Поиск |
FAQ |
Статьи |
Книги |
Новости VCL
| | Форумы ЧАТ |
Орешник |
|
| |||
| |||
| |||
« предыдущая ветвь | форум | следующая ветвь »
Разнесение данных по двум таблицам: имеел ли смысл? [MSSQL]
Ega23 © (2005-08-04 12:25:00)Есть 2 таблциы:
create table Classes (
CLSID int not null,
ParCLSID int null,
CLSGUID uniqueidentifier not null,
CLSNam varchar(64) not null,
CLSTableNam varchar(64) default '' not null,
AbstractFl tinyint not null,
constraint PK_CLASSES primary key (CLSID)
)
go
print 'Создание таблицы Classes'
alter table Classes
add constraint FK_CLASSES_REFERENCE_CLASSES foreign key (ParCLSID)
references Classes (CLSID)
go
create table ClassesAdd (
UNID int Identity(0,1) not null,
CLSID int not null,
CLSLab varchar(64) not null,
CLSMultiLab varchar(64) not null,
CLSImg image null,
CLSMultiImg image null,
constraint PK_CLASSESADD primary key (UNID)
)
go
print 'Создание таблицы ClassesAdd'
alter table ClassesAdd
add constraint FK_CLASSESA_REFERENCE_CLASSES foreign key (CLSID)
references Classes (CLSID)
go
В принципе, сущность данных - одна и та же. Можно всё в одну таблицу запихать. Только вот к первой таблице будут очень частые запросы идти, а ко второй - наоборот очень редко.
Как думаете, что более оптимальное - оставить так, как есть, или объединить эти 2 таблицы в одну?
Petr V. Abramov (2005-08-05 00:47:00) [1]Если при запросах гарантированно не будет full table scan, то лучше в одну таблицу, так теоретически правильней. В противном случае "хвост из блобов" (если они физически в MSSQL не хранатся отдельно) и пр. лабуда создадут тормоза
Anatoly Podgoretsky (2005-08-04 20:12:00) [2]Ega23 © (04.08.05 12:30) [3]
При связи один к одному разделяют обычно только, если есть физические ограничения на запись. Других причин не должно приниматься во внимание.
Ega23 (2005-08-04 14:38:00) [3]2 Rule © (04.08.05 14:30) [21]
Да я уже час назад переделал и SP написал... :о)
Rule (2005-08-04 14:30:00) [4]ну единогласно решили, что стоит одну :-)
Ega23 (2005-08-04 13:51:00) [5]Ну в MS SQL блобы, (также как и varchar, кстати) действительно являются указателями, а сами данные где-то в heap'е хранятся...
evvcom (2005-08-04 13:40:00) [6]Я думаю, что все бренды хорошие идеи так или иначе заимствуют друг у друга (или у стандарта :) ). Поэтому, думаю, внутренне будет похоже на Оракл. В Оракле поля записей со значениями null вообще не занимают места, а на блобы хранятся ссылки (или опять же не хранятся, если null), поэтому на размер это не повлияет, на скорость при выборке части данных (из table Classes) тоже не должно, а при выборке всех нужных данных в случае с ClassesAdd ты действительно потеряешь на джойнах.
Desdechado (2005-08-04 13:28:00) [7]обычно в страницах данных хранятся только указатели на блобы, а сами блобы на отдельных страницах
возможны варианты, конечно, но это позволяет серверу не читать страницы с блобами, если их пользователь не просит
Ega23 (2005-08-04 13:24:00) [8]Значит всё-таки одна таблица...
А на скорости, говорите, не скажется...
Добро, буду исправлять...
Johnmen (2005-08-04 13:04:00) [9]>Ega23 ©
>не будет ли тормозить выборки такой хвост из BLOB-ов?
>А остальное - ты ТОЧНО УВЕРЕН?
Я лично уверен, что скорость будет практически одинаковой.
При условии, что количество записей в обеих тбл одинаково.
Теоретически разница будет, но её не уловишь при всём старании...:)
Sergey13 (2005-08-04 13:01:00) [10]Я не знаком с МС, посему это просто рассуждения.
Чисто теоретически, чем меньше полей, тем больше записей считается при единичной операции чтения данных. Особенно это скажется при полном сканировании таблицы. Если же доступ будет в основном по индексу, то это преимущество практически сходит на 0.
На 2 таблицах будешь постоянно терять на объединении.
На 1 таблице проще поддерживать целостность и непротиворечивость (собственно вообще не надо поддерживать 8-).
Я бы сделал 1 таблицу.
Андрей Жук (2005-08-04 12:57:00) [11]Сделай разные вьюхи, на часто и редко используемые данные.
Ega23 (2005-08-04 12:52:00) [12]Не ставь *, а пиши имены выбираемых полей (исключая BLOB-поля, естественно), тогда не будут.
Ну * я вообще использую срайне редко. В основном в конструкции Count(*).
А остальное - ты ТОЧНО УВЕРЕН?
ЮЮ (2005-08-04 12:48:00) [13]собственно говоря - не будет ли тормозить выборки такой хвост из BLOB-ов?
Не ставь *, а пиши имены выбираемых полей (исключая BLOB-поля, естественно), тогда не будут.
Ega23 (2005-08-04 12:43:00) [14]2 DiamondShark © (04.08.05 12:39) [9]
Я бы все image не только в отдельную таблицу вынес, но ещё бы и в другой файл.
В смысле ещё один mdf создать???
Ega23 (2005-08-04 12:42:00) [15]ну я думаю 70% это достаточно чтобы в одну таблицу запихать
Дело в том, что к этой таблице (Classes) действительно дофига запросов будет идти, поэтому её нужно составить максимально оптимально. И изначальный вопрос, собственно говоря - не будет ли тормозить выборки такой хвост из BLOB-ов?
DiamondShark (2005-08-04 12:39:00) [16]Всё правильно.
Я бы все image не только в отдельную таблицу вынес, но ещё бы и в другой файл.
Ega23 (2005-08-04 12:39:00) [17]Почему тогда CLSImg null ? Если уж вынесены, то not null, ибо без CLSImg можно и в Classes отсидеться :)
Null - потому что это иконка на Action. Которого (action) вполне может и не быть. Или как раз специально без картинки...
В общем это вполне сознательно сделано и полностью соответствует уже сложившимуся стилю программирования группы.
Rule (2005-08-04 12:37:00) [18]Ega23 © (04.08.05 12:35) [5]
ну я думаю 70% это достаточно чтобы в одну таблицу запихать
ЮЮ (2005-08-04 12:36:00) [19]>В неё вынесены иконки и названия для пользовательского интерфейса.
Почему тогда CLSImg null? Если уж вынесены, то not null, ибо без CLSImg можно и в Classes отсидеться :)
Ega23 (2005-08-04 12:35:00) [20]2 Rule © (04.08.05 12:32) [4]
так как для каждого класса есть иконка и название пользовательского интерфейса
Э нет, я неточно выразился. Иконки и названия будут где-то у 70% записей таблицы Classes.
| |
Страницы: 