Таблицы с большим количеством полей в 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)
Почему? А если например только части записей из одной таблицы соответствует одна запись из второй?

Anatoly Podgoretsky © (28.06.05 14:18) [11] Так у него 1 ко многим
101, Такоев Сякой
102, Сякоев Такой
-----------------
101, 12.12.2004, 200.05
101, 01.02.2004, 314.56

Sergey13 © (28.06.05 14:22) [12]
Это уже one to many relation
У автора вопрос про one to one relation
Место для применения я указал - технические ограничения на таблицу.

Mike Kouzmine © (28.06.05 14:23) [13]
Это уже другой вопрос. Я не виноват, что он не умеет выражать свои мысли.

2 [14] Anatoly Podgoretsky © (28.06.05 14:42)
>Это уже one to many relation
>У автора вопрос про one to one relation
>Место для применения я указал - технические ограничения на таблицу.

Может я чего не понимаю, но вроде я о том же и говорю.
Пример. Есть таблица. В ней мужчины и женщины. Причем только на мужчин заполняется многочисленная инфа.
Почему, если я создам вторую таблицу (под мужиков) с ключом, равным ключу из первой таблицы, и многочисленными другими полями это будет "одна из самых грубейших нарушений нормализации"? Ведь тут именно one to one relation.

Речь идет про уменьшение количества полей, напримере, пусть есть таблица такого рода
ID, A, B, C
Делаем три таблицы
ID, A
ID, B
ID, C
Теперь у нас три таблицы по два поля.

замечу, что в FB существует ограничение на длину записи
из этого следует:
1. многопольные таблицы большая редкость, если грамотноподойти к предметной области
2. даже если все правильно, то не всегда получится затолкать 80 полей в одну таблицу

и еще узелок на память:
таблицы удобны тем, что их можно бесконечно наращивать в длину, не нарушая логики взаимосвязи полей и не переписывая программу
если в длину не получается, то:
1. либо надо повернуть таблицу на 90 градусов
2. либо пересмотреть структуру с учетом нормализации

Таблицы с большим количеством полей в Firebird Найти похожие ветки