Разнесение данных по двум таблицам: имеел ли смысл?

← →
Ega23 © (2005-08-04 12:25) [0]

Есть 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 таблицы в одну?

← →
ANB © (2005-08-04 12:28) [1]

Связки один к одному ?

← →
Rule © (2005-08-04 12:30) [2]

думаю надо все в одну, если они логически родственны, если логика разная (имею ввиду бизнесс-логику, тоесть физический смысл), то нада разносить чтоб не запутать себя и других, ИМХО конечно

← →
Ega23 © (2005-08-04 12:30) [3]

Да. Фактически таблица ClassesAdd - продолжение таблицы Classes. В неё вынесены иконки и названия для пользовательского интерфейса.

← →
Rule © (2005-08-04 12:32) [4]

Ega23 © (04.08.05 12:30) [3]
так как для каждого класса есть иконка и название пользовательского интерфейса, то можно предположить, что целесообразней все хранить в одной таблице а выбирать только те поля которые действительно нужны ...

← →
Ega23 © (2005-08-04 12:35) [5]

2 Rule © (04.08.05 12:32) [4]
так как для каждого класса есть иконка и название пользовательского интерфейса

Э нет, я неточно выразился. Иконки и названия будут где-то у 70% записей таблицы Classes.

← →
ЮЮ © (2005-08-04 12:36) [6]

>В неё вынесены иконки и названия для пользовательского интерфейса.

Почему тогда CLSImg null ? Если уж вынесены, то not null, ибо без CLSImg можно и в Classes отсидеться :)

← →
Rule © (2005-08-04 12:37) [7]

Ega23 © (04.08.05 12:35) [5]
ну я думаю 70% это достаточно чтобы в одну таблицу запихать

← →
Ega23 © (2005-08-04 12:39) [8]

Почему тогда CLSImg null ? Если уж вынесены, то not null, ибо без CLSImg можно и в Classes отсидеться :)

Null - потому что это иконка на Action. Которого (action) вполне может и не быть. Или как раз специально без картинки...
В общем это вполне сознательно сделано и полностью соответствует уже сложившимуся стилю программирования группы.

← →
DiamondShark © (2005-08-04 12:39) [9]

Всё правильно.
Я бы все image не только в отдельную таблицу вынес, но ещё бы и в другой файл.

← →
Ega23 © (2005-08-04 12:42) [10]

ну я думаю 70% это достаточно чтобы в одну таблицу запихать

Дело в том, что к этой таблице (Classes) действительно дофига запросов будет идти, поэтому её нужно составить максимально оптимально. И изначальный вопрос, собственно говоря - не будет ли тормозить выборки такой хвост из BLOB-ов?

← →
Ega23 © (2005-08-04 12:43) [11]

2 DiamondShark © (04.08.05 12:39) [9]
Я бы все image не только в отдельную таблицу вынес, но ещё бы и в другой файл.

В смысле ещё один mdf создать???

← →
ЮЮ © (2005-08-04 12:48) [12]

собственно говоря - не будет ли тормозить выборки такой хвост из BLOB-ов?

Не ставь *, а пиши имены выбираемых полей (исключая BLOB-поля, естественно), тогда не будут.

← →
Ega23 © (2005-08-04 12:52) [13]

Не ставь *, а пиши имены выбираемых полей (исключая BLOB-поля, естественно), тогда не будут.

Ну * я вообще использую срайне редко. В основном в конструкции Count(*).
А остальное - ты ТОЧНО УВЕРЕН?

← →
Андрей Жук © (2005-08-04 12:57) [14]

Сделай разные вьюхи, на часто и редко используемые данные.

← →
Sergey13 © (2005-08-04 13:01) [15]

Я не знаком с МС, посему это просто рассуждения.

Чисто теоретически, чем меньше полей, тем больше записей считается при единичной операции чтения данных. Особенно это скажется при полном сканировании таблицы. Если же доступ будет в основном по индексу, то это преимущество практически сходит на 0.
На 2 таблицах будешь постоянно терять на объединении.
На 1 таблице проще поддерживать целостность и непротиворечивость (собственно вообще не надо поддерживать 8-).

Я бы сделал 1 таблицу.

← →
Johnmen © (2005-08-04 13:04) [16]

>Ega23 ©
>не будет ли тормозить выборки такой хвост из BLOB-ов?
>А остальное - ты ТОЧНО УВЕРЕН?

Я лично уверен, что скорость будет практически одинаковой.
При условии, что количество записей в обеих тбл одинаково.
Теоретически разница будет, но её не уловишь при всём старании...:)

← →
Ega23 © (2005-08-04 13:24) [17]

Значит всё-таки одна таблица...
А на скорости, говорите, не скажется...
Добро, буду исправлять...

обычно в страницах данных хранятся только указатели на блобы, а сами блобы на отдельных страницах
возможны варианты, конечно, но это позволяет серверу не читать страницы с блобами, если их пользователь не просит

Я думаю, что все бренды хорошие идеи так или иначе заимствуют друг у друга (или у стандарта :) ). Поэтому, думаю, внутренне будет похоже на Оракл. В Оракле поля записей со значениями null вообще не занимают места, а на блобы хранятся ссылки (или опять же не хранятся, если null), поэтому на размер это не повлияет, на скорость при выборке части данных (из table Classes) тоже не должно, а при выборке всех нужных данных в случае с ClassesAdd ты действительно потеряешь на джойнах.

Ну в MS SQL блобы, (также как и varchar, кстати) действительно являются указателями, а сами данные где-то в heap"е хранятся...

ну единогласно решили, что стоит одну :-)

Ega23 © (04.08.05 12:30) [3]
При связи один к одному разделяют обычно только, если есть физические ограничения на запись. Других причин не должно приниматься во внимание.

Если при запросах гарантированно не будет full table scan, то лучше в одну таблицу, так теоретически правильней. В противном случае "хвост из блобов" (если они физически в MSSQL не хранатся отдельно) и пр. лабуда создадут тормоза

Разнесение данных по двум таблицам: имеел ли смысл? Найти похожие ветки