Нормализация таблицы

Я пытаюсь создать простую программу регистрации, используя VB.Net и MySQL для своей базы данных. Вот моя простая таблица для основной информации

введите здесь описание изображения

Тем не менее, я пытаюсь улучшить свои базовые знания в области нормализации таблицы, и поэтому я разделил поле «Дата», чтобы избежать, скажем, в один день повторной вставки одной и той же даты. Я имею в виду, когда 50 человек зарегистрировались за один день, он просто добавит одну дату (запись) в таблицу tblRegDate вместо добавления ее 50 раз в таблицу. Есть какой-либо способ сделать это? Возможно ли это в VB.Net и MySQL? Или, скорее, я должен добавить или изменить какое-то поле? или я должен сделать условие в VB.Net? Приведенная выше таблица — это то, чему меня научил мой друг, но я обнаружил, что она не устраняет избыточность. Пожалуйста, дайте мне какие-либо инструкции или направьте меня на сайт, где есть простой учебник для этого. Заранее спасибо!

вот мои коды MySQL:

CREATE TABLE tblInfo(
       Number INT AUTO_INCREMENT,
       LastName VARCHAR(45),
       FirstName VARCHAR(45),
       MiddleName VARCHAR(45),
       Gender ENUM(M,F),
       BirthDate DATE,
       PRIMARY KEY(Number));

CREATE TABLE tblRegDate(
       IDRegDate INT AUTO_INCREMENT,
       Date TIMESTAMP,
       Number INT,
       PRIMARY KEY(IDRegDate),
       FOREIGN KEY(Number) REFERENCES tblInfo(Number));

mysql vb.net database-normalization normalization
person Aaron    schedule 21.10.2011    source источник
comment
Я думаю, вам следует просто сохранить поле RegDate в информационной таблице.   -  person AndrewR    schedule 21.10.2011
comment
Хранилище, необходимое для одного столбца DATE в таблице tblInfo, будет примерно того же размера, что и хранилище для значения внешнего ключа, поэтому экономия места минимальна; стоимость присоединения к таблице tblRegDate перевешивает любую экономию. Техника не обязательно автоматически плоха; это просто не убедительный пример использования техники.   -  person Jonathan Leffler    schedule 21.10.2011

Ответы (3)


arrow_upward
2
arrow_downward

Как я вижу, в этом случае у вас нет преимуществ разделения одного поля. Вы потеряете много производительности.

Нормализация таблицы не означает отсутствие избыточного значения. Это больше о «разделении проблем»

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

Вопрос: Есть ли дополнительная информация по регистрации? Например, веб-страница, IP, .....

Затем у вас должно быть две таблицы, например «Лицо» и «Регистрация». Тогда у вас будут две семантически разные вещи, которые не следует смешивать.

Есть много примеров и информации, которую вы можете найти через Google. и википедия http://en.wikipedia.org/wiki/Database_normalization

person Boas Enkler    schedule 21.10.2011
comment
Спасибо ... ваш ответ мне поможет. - person Aaron; 21.10.2011

arrow_upward
1
arrow_downward

На самом деле не рекомендуется отделять метку времени от таблицы.
Вам понадобится другая таблица, а именно timeTable. У него будет два идентификатора столбца и временная карта, и вы должны ссылаться на этот идентификатор в своей таблице tblRegDate как на внешний ключ. Внешний ключ является целым числом и имеет размер 4 байта. Дата с другой стороны 3 байта.

Поэтому я бы рекомендовал вам хранить дату в tblRegDate, а не в дополнительной таблице.

person Kayser    schedule 21.10.2011

arrow_upward
1
arrow_downward

Когда вы нормализуете структуры БД, всегда помните об ACID — http://en.wikipedia.org/wiki/ACID

Основываясь на полях, которые у вас есть, вы должны просто сохранить их как одну таблицу. Выделение даты регистрации — не лучший вариант, потому что вам придется каждый раз искать ее. В реальной жизни вы можете подумать об индексации даты регистрации, если ваше приложение всегда выполняет поиск или сортировку по дате регистрации.

И если вы FK RegDate таблицы для пользовательской таблицы, то это тоже не эффективно.

p.s. Также имейте в виду, что существует 4 уровня нормализации БД. Если вы новичок в проектировании БД, вам следует подумать о том, как переместить проект БД из 1-й во 2-ю и со 2-й в 3-ю нормальные формы.

Мы редко используем 4-ю нормальную форму в реальной жизненной ситуации. Системы транзакций обычно остаются на 3-м месте большую часть времени.

Надеюсь, это имеет смысл.

person Glorithm    schedule 21.10.2011
comment
Существует (как минимум) ШЕСТЬ пронумерованных нормальных форм, а не четыре. Есть и другие, такие как BCNF, DKNF и EKNF. 5-я нормальная форма, вероятно, наиболее часто используется в реальной жизни. - person nvogel; 21.10.2011