Оптимизация количества таблиц

есть ли какие-либо рекомендации по кол-ву таблиц базе данных.
что эффективнее - большее число таблиц или наоборот - минимум таблиц с кучей информации?

0

Рекомендую почитать учебник по теории реляционных БД. Ваш вопрос решится сам собой.

А на Ваш вопрос можно ответить так:
В БД должно быть столько таблиц, сколько Вам необходимо(разумеется большинство из должны быть в 3НФ)

P.S. Если у кого-то есть иное мнение - присоединяйтесь - обсудим...

0

спасибо,

3НФ ?

......
необходимо мне конечно минимум - путатся меньше буду...
просто возникла мысль, что при работе только с частью данных из одной таблицы, оставшаяся часть безцельно 'перелистывается'...
или я не прав?

0

>спасибо,
>
>3НФ ?
>

3НФ - 3-я нормальная форма(также она носит название формы Бойса-Кодда)

>просто возникла мысль, что при работе только с частью данных из >одной таблицы, оставшаяся часть безцельно 'перелистывается'...
>или я не прав?

не совсем... При работе только с некоторыми полями таблица полученными с помощью запроса остальные поля ИМХО не будут 'перелистываться'. У кого есть иное видение этого вопроса - пишите в тему - подискутируем.

Удачи.

0

моя база состоит из 23 таблиц, хотя можно было бы обойтись и одной. Но при построении сложных запросов (с большим количеством подзапросов)у меня не возникает необходимости создавать промежуточные таблицы, соответственно я почти не использую запросы на создание таблиц, удаление и добавление записей, обходясь практически одними селектами.
Вывод: лучше больше таблиц.

а если бы была одна таблица можно было бы обойтись одним только фильтром...
и из него делать временную таблицу.
нет?

0

По поводу 3НФ - нормальная форма Бойса-Кодда не то же самое (она строже 3-й, точнее, к сожалению, сейчас не припомню). А сколько нужно таблиц - это зависит от конкретной задачи, но скорее всего обойтись одной - плохая идея. Если бы Вы точнее описали задачу на вопрос можно было бы ответить более однозначно...

0

- поставщики
- товар (все коды - внутренний, EAN, цены, поставщик на данный момент)
- продажи по дням
- приход от поставщика по месяцам
- возврат поставщику по месяцам
- список акций, акционных товаров, размер дискаунта

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

0

Тут я бы очень советовал одной таблицы не делать, т.к. хоть товары с поставщиками и не связаны, но связи между другими таблицами вполне однозначны. А одна таблица будет ненормализованной, что влечёт за собой избыточность данных, аномалии вставки, удаления и обновления - пренеприятнейшие штуки, о которых можно узнать из любой литературы о реляционных базах данных

0

Прочитал только что из: 'http://top-business.hut.ru/mysql-help/2.html'
по поводу нормализации.
Из своево опыта:
создавал и вел 'базу производства' на малом предприятии.
Пришел к некоторым принципам формирования таблиц.
Принцип А: Таблица может быть одного из двух типов:
1) без полей связи (основная табл.)
2) с полями связи (таблица связи)
Принцип B: Основная таблица должна иметь как минимум 2 поля:
1) поле-идентификатор (ID,код), лучше числовое
2) поле-имя (имя)- текстовое поле, объясняющее, что за объект скрывается под ID, кодом
3)
... поля-свойства объекта, которые неразрывно связанны с объектом
n)

Таблица связи обязательно содержит как минимум 2 поля, в т.числе 1 поле связи с другой таблицей.
Я абсолютно не разбираюсь в торговле, но в вашем случае сделап бы такие таблицы (в <>скобках необязательные поля:
- 'поставщики' (КодПоставщика-ID, Поставщик-текст, <АдресПоставщика>, <ТелефонПоставщика>, ...
- 'товар' (КодТовара-ID, Товар-текст, <Свойство1Товара>, <Свойство2Товара>, ...
-'поставки' (КодПоставки-ID, <ИмяПоставки - например: 'Соки', 'Мороженое'>, КодТовара, КодПоставщика, Объем поставки(кол-во), ЦенаЕдцыОбъема, <ЦенаПартии-вычисляемое поле>, ДатаПоставки, Остаток-программно связать с изменениями в табл 'продажи по дням'
- 'продажи по дням' (КодПоставки, ДатаПродажи, Продано :кол-во, ЦенаПродажиЗаЕдцуТовара, СуммаПродажи-вычисляемое)
- приход от поставщика по месяцам - это может быть не таблица, а отчет (программно)-выборка за период по товарам, поставщику и т.д из табл.'поставки'
- 'возврат поставщику по месяцам' - аналогично предыдущей табл
- 'список акций, акционных товаров, размер дискаунта' - в этом я не разбираюсь, но наверное, как-то связать с табл.'продажи по дням' или включить в нее.

0

продолжение:
Извиняюсь, в табл 'продажи по дням' такие поля (КодПродажи, КодТовара, ДатаПродажи, Продано:кол-во, ЦенаПродажиЗаЕдцуТовара, СуммаПродажи-вычисляемое). После заполнения записи или группы записей в этой таблице (по нажатию кнопки 'Ок' в форме 'Продажи' с этой таблицей)-программно вычислять 'Остаток' для табл. 'Поставки' по каждому товару с более ранней датой закупки, пока он (остаток) больше нуля.

0