Мастера DELPHI (документация, исходники, скачать)

Основная («Начинающим»)/ Базы / WinAPI / Компоненты / Сети / Media / Игры / Corba и COM / KOL / FreePascal / .Net / Прочее / RSDN.ORG

« предыдущая ветвь | форум | следующая ветвь »

Таблицы с большим количеством полей в Firebird [D6, Firebird 1.5]

Sirus © (2005-06-28 08:27:00)
Привет Мастера...
Есть вопрос: Что лучше? Создать одну таблицу с большим количеством полей (у меня их около 80) или создать несколько таблиц с менишьим количеством полей и привязать их по одному полю (скажем код записи)?

Desdechado (2005-06-28 21:00:00) [1]
замечу, что в FB существует ограничение на длину записи
из этого следует:
1. многопольные таблицы большая редкость, если грамотноподойти к предметной области
2. даже если все правильно, то не всегда получится затолкать 80 полей в одну таблицу

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

Anatoly Podgoretsky (2005-06-28 16:45:00) [2]
Речь идет про уменьшение количества полей, напримере, пусть есть таблица такого рода
ID, A, B, C
Делаем три таблицы
ID, A
ID, B
ID, C
Теперь у нас три таблицы по два поля.

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

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

Mike Kouzmine (2005-06-28 15:02:00) [4]
Anatoly Podgoretsky © (28.06.05 14:42) [14] А Вас никто ни в чем и не обвиняет. :)

Anatoly Podgoretsky (2005-06-28 14:42:00) [5]
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 14:23:00) [6]
Anatoly Podgoretsky © (28.06.05 14:18) [11] Так у него 1 ко многим
101, Такоев Сякой
102, Сякоев Такой
-----------------
101, 12.12.2004, 200.05
101, 01.02.2004, 314.56

Sergey13 (2005-06-28 14:22:00) [7]
2[11] Anatoly Podgoretsky © (28.06.05 14:18)
Почему? А если например только части записей из одной таблицы соответствует одна запись из второй?

Anatoly Podgoretsky (2005-06-28 14:18:00) [8]
Virgo_Style © (28.06.05 14:08) [8]
Разбивают на отдельные таблицы не для уменьшения размера, а совсем по другим причинам. Связь один ко одному одна из самых грубейших нарушений нормализации. На нее можно идти только по техническим причинам.

Virgo_Style (2005-06-28 14:17:00) [9]
Mike Kouzmine © (28.06.05 14:11) [9]

А, я дурак, не обратил внимания, что они повторяются =)

Mike Kouzmine (2005-06-28 14:11:00) [10]
Virgo_Style © (28.06.05 14:08) [8] Нет повторяющихся значений символьных полей.

Virgo_Style (2005-06-28 14:08:00) [11]
Sirus (28.06.05 9:05) [5]
Но от этого разрастается база данных

Может, я чего-то не понимаю, но как разбиение на отдельные таблицы может уменьшить размер базы, если там будут храниться те же данные плюс ключи?

Digitman (2005-06-28 14:01:00) [12]
http://www.interbase-world.com/ru/book/articles/928.php

Sirus (2005-06-28 09:13:00) [13]
И еще: Я не совсем понимаю что такое ключ и зачем он нужен. Спросим так: Помогает ли ключ связать одну запись из первой таблицы с несколькими записями из второй таблицы?

Sirus (2005-06-28 09:05:00) [14]
Скажем так: Есть поля (Код абонента, Ф.И.О. Дата и Сумма баланса и много чего по мелочи). Если я запихну все в одну таблицу то получиться так:
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 (много всяких условий)
Вопрос: Как можно все это ускорить?

Anatoly Podgoretsky (2005-06-28 08:54:00) [15]
Sirus (28.06.05 08:27)
Количество полей не самоцель. Делать связи 1-1 можно, но теоритически неверно.

Digitman (2005-06-28 08:38:00) [16]

> Что лучше?

лучше сначала подумать, какие выборки планируется выполнять в дальнейшем и какие индексы потребуются ... от этого немало зависит скорость выполнения запросов

Zacho (2005-06-28 08:35:00) [17]
От задачи зависит.
"Таблица с большим количеством полей" нормализована ?

Ярослав (2005-06-28 08:34:00) [18]
В любой книге по БД есть правила нормализации, вот их и нужно почитать, тогда все ясно станет

Наверх

	« предыдущая ветвь \| форум \| следующая ветвь »