Форум: "Базы";
Текущий архив: 2005.08.07;
Скачать: [xml.tar.bz2];
ВнизТаблицы с большим количеством полей в Firebird Найти похожие ветки
← →
Sirus (2005-06-28 08:27) [0]Привет Мастера...
Есть вопрос: Что лучше? Создать одну таблицу с большим количеством полей (у меня их около 80) или создать несколько таблиц с менишьим количеством полей и привязать их по одному полю (скажем код записи)?
← →
Ярослав (2005-06-28 08:34) [1]В любой книге по БД есть правила нормализации, вот их и нужно почитать, тогда все ясно станет
← →
Zacho © (2005-06-28 08:35) [2]От задачи зависит.
"Таблица с большим количеством полей" нормализована ?
← →
Digitman © (2005-06-28 08:38) [3]
> Что лучше?
лучше сначала подумать, какие выборки планируется выполнять в дальнейшем и какие индексы потребуются ... от этого немало зависит скорость выполнения запросов
← →
Anatoly Podgoretsky © (2005-06-28 08:54) [4]Sirus (28.06.05 08:27)
Количество полей не самоцель. Делать связи 1-1 можно, но теоритически неверно.
← →
Sirus (2005-06-28 09:05) [5]Скажем так: Есть поля (Код абонента, Ф.И.О. Дата и Сумма баланса и много чего по мелочи). Если я запихну все в одну таблицу то получиться так:
101, Такоев Сякой, 12.12.2004, 200.05
101, Такоев Сякой, 01.02.2005, 314.56
102, Сякоев Такой, 12.12.2004, 151.00
102, Сякоев Такой, 01.02.2005, 103.71
Выборка из такой таблицы будет производиться быстро, да и удобнее тоже... Но от этого разрастается база данных (что в свою очередь тормозит работу базы). Я разбил это на несколько таблиц:
101, Такоев Сякой
102, Сякоев Такой
-----------------
101, 12.12.2004, 200.05
101, 01.02.2004, 314.56
и т.д.
Но и в таком случае при больших количествах записей скорость работы базы оставляет желать лучшего.
запрос типа select * from table1, table2 where table1.scode=table2.scode and (много всяких условий)
Вопрос: Как можно все это ускорить?
← →
Sirus (2005-06-28 09:13) [6]И еще: Я не совсем понимаю что такое ключ и зачем он нужен. Спросим так: Помогает ли ключ связать одну запись из первой таблицы с несколькими записями из второй таблицы?
← →
Digitman © (2005-06-28 14:01) [7]http://www.interbase-world.com/ru/book/articles/928.php
← →
Virgo_Style © (2005-06-28 14:08) [8]Sirus (28.06.05 9:05) [5]
Но от этого разрастается база данных
Может, я чего-то не понимаю, но как разбиение на отдельные таблицы может уменьшить размер базы, если там будут храниться те же данные плюс ключи?
← →
Mike Kouzmine © (2005-06-28 14:11) [9]Virgo_Style © (28.06.05 14:08) [8] Нет повторяющихся значений символьных полей.
← →
Virgo_Style © (2005-06-28 14:17) [10]Mike Kouzmine © (28.06.05 14:11) [9]
А, я дурак, не обратил внимания, что они повторяются =)
← →
Anatoly Podgoretsky © (2005-06-28 14:18) [11]Virgo_Style © (28.06.05 14:08) [8]
Разбивают на отдельные таблицы не для уменьшения размера, а совсем по другим причинам. Связь один ко одному одна из самых грубейших нарушений нормализации. На нее можно идти только по техническим причинам.
← →
Sergey13 © (2005-06-28 14:22) [12]2[11] Anatoly Podgoretsky © (28.06.05 14:18)
Почему? А если например только части записей из одной таблицы соответствует одна запись из второй?
← →
Mike Kouzmine © (2005-06-28 14:23) [13]Anatoly Podgoretsky © (28.06.05 14:18) [11] Так у него 1 ко многим
101, Такоев Сякой
102, Сякоев Такой
-----------------
101, 12.12.2004, 200.05
101, 01.02.2004, 314.56
← →
Anatoly Podgoretsky © (2005-06-28 14:42) [14]Sergey13 © (28.06.05 14:22) [12]
Это уже one to many relation
У автора вопрос про one to one relation
Место для применения я указал - технические ограничения на таблицу.
Mike Kouzmine © (28.06.05 14:23) [13]
Это уже другой вопрос. Я не виноват, что он не умеет выражать свои мысли.
← →
Mike Kouzmine © (2005-06-28 15:02) [15]Anatoly Podgoretsky © (28.06.05 14:42) [14] А Вас никто ни в чем и не обвиняет. :)
← →
Sergey13 © (2005-06-28 15:22) [16]2 [14] Anatoly Podgoretsky © (28.06.05 14:42)
>Это уже one to many relation
>У автора вопрос про one to one relation
>Место для применения я указал - технические ограничения на таблицу.
Может я чего не понимаю, но вроде я о том же и говорю.
Пример. Есть таблица. В ней мужчины и женщины. Причем только на мужчин заполняется многочисленная инфа.
Почему, если я создам вторую таблицу (под мужиков) с ключом, равным ключу из первой таблицы, и многочисленными другими полями это будет "одна из самых грубейших нарушений нормализации"? Ведь тут именно one to one relation.
← →
Anatoly Podgoretsky © (2005-06-28 16:45) [17]Речь идет про уменьшение количества полей, напримере, пусть есть таблица такого рода
ID, A, B, C
Делаем три таблицы
ID, A
ID, B
ID, C
Теперь у нас три таблицы по два поля.
← →
Desdechado © (2005-06-28 21:00) [18]замечу, что в FB существует ограничение на длину записи
из этого следует:
1. многопольные таблицы большая редкость, если грамотноподойти к предметной области
2. даже если все правильно, то не всегда получится затолкать 80 полей в одну таблицу
и еще узелок на память:
таблицы удобны тем, что их можно бесконечно наращивать в длину, не нарушая логики взаимосвязи полей и не переписывая программу
если в длину не получается, то:
1. либо надо повернуть таблицу на 90 градусов
2. либо пересмотреть структуру с учетом нормализации
Страницы: 1 вся ветка
Форум: "Базы";
Текущий архив: 2005.08.07;
Скачать: [xml.tar.bz2];
Память: 0.49 MB
Время: 0.039 c