У меня БД частного брачного агенства.
Все данные хранятся в одной таблице "Анкеты". Там много повторяющейся информации. Например для каждого клиента указывается национальность. название города, знак зодиака . образование. Ну все это в текстовом виде.
Как поступить с точки зрения теории нормализации я знаю. Но думаю стоит ли?
Скажем база будет работать на мощном компе с большим количеством оперативных мозгов. Место на винте , также предостаточно. Тормозов быть не должно. Индексов наделал. Количество записей больше 30000 тысяч не будет .

Вроде по идее напрашивается мысль нормализовать таблицу с анкетами. Ведь одна из причин применения нормализации состоит в более эффективном хранении информации в базе. Т.е инфа не дублируется. Проще организовать доступ к таблице. Но все таки есть и плюсы хранения данные в одной таблице.

Как думаете все таки стоит менять структуру таблицы "Анкета" , чтобы получить n-ное число нормализованных таблиц? Или с учетом , что база будет работать на мощном компе не стоит и оставить все в одной таблице?

2 ВС
Думаете все таки надо нормализовать структуру?

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

2 ЛП

Не надо модерить.

Понятно.

2 ВС
>А это уже будет нормализация.

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

Поясню что я имел ввиду.

Нормализация это когда у меня будет следующее:

Создам таблицу где буду хранить названия национальностей и ключевыи полем будет скажем числовое "код национальности".
В подчиненной таблице уже не буду создавать поле где будет храниться название национальности, а создам числовое поле внешнего ключа( код национальности) . Останется связать таблицы 1:М.
При выборе национальности в таблицу анкет попадет код национальности. Это нормализация.

Но.
Я имел ввиду. Что будут две таблицы. Национальности (в них только название национальностей) и Анкета (там тоже будет текстовое поле национальность).
Юзер сможет занести в таблицу Анкета только значение из таблицы Национальности. Никаких ключей , связей.

Один хрен.Если отсутствует какая то национальность, то нужно ее заносить в отдельную таблицу. А с нормализацией нужно еще и код национальности вносить.

В любом случае получается пополам. Можно и без нормализации обойтись мне кажется. К примеру запросы на обновление здесь не нужны.

2 ВС

Ну да создать отдельную таблицу с одним ключевым полем "название национальности" и в подчиненной создать тоже текстовое поле как внешний ключ. Да , таблицы связаны. Вроде бы нормализация. Но все равно дубляж !
Числовое поле естественно меньше "сожрет " места. Но так уж это важно, если база по сути не большая и на винте места полно?

Полностью избежать дублирования всё таки нельзя. Все равно в подчиненной будет дубляж , уж если не названий национальностей,то их кодов. Но это эффективней, чем хранить название национальностей всюду.

2 ЛП
Да я уже запросов / форм / процедур и функций кучу на VBA/DAO наклепал ... Вроде все чудненько. Но проверил работу базы с 80 тыс. записей и сел в лужу.
База больше минуты запускалась (море же индексов) вот я и подумал , что надо может нормализовать большую таблицу. Не смейся , скажешь "раньше надо было думать", а я прикинул и решил обойтись без нормализации.

Да напрямую , попробуй таблицу скажем с 20 полями без индексов забить 50000 записями. А потом добавь индексы почти к любому полю. И посмотри на закономерные "тормоза".

В лужу я еще пока не совсем сел Если только стою в ней одной ногой. Хотя как сказать еще.