Форум программистов, компьютерный форум, киберфорум
C#: Web, ASP.NET
Войти
Регистрация
Восстановить пароль
 
Рейтинг 5.00/5: Рейтинг темы: голосов - 5, средняя оценка - 5.00
0 / 0 / 0
Регистрация: 23.05.2007
Сообщений: 236
1

Что лучше: одна таблица или две?

29.05.2007, 07:03. Просмотров 1018. Ответов 7
Метки нет (Все метки)


Что лучше для скрипта новстей (две колонки с разной информацией, обновление раз в неделя) одна таблица в БД или две разных, будет ли 1 табл. тормозить поиск и работу с бд (Access 2000), данных то будет больше, или я не прав...
0
Programming
Эксперт
94731 / 64177 / 26122
Регистрация: 12.04.2006
Сообщений: 116,782
29.05.2007, 07:03
Ответы с готовыми решениями:

Что лучше RS в объект или RS в объекте
Есть ASP страница, которая делает соединение сбазой и запрашивает несколько выборок. Есть серверный...

Парсинг или серилизация: что лучше использовать
Здравствуйте. Сейчас разбираюсь с API ToDo.ly и думаю что лучше... Парсить ответный XML присваивая...

Что лучше выбрать: Сокеты или NetworkStream?
Всем привет. У меня такая задача: сделать сервер на ПК, а клиенты - на смартфонах андроид. Мне...

Что лучше для написания бота? C# или Python?
Доброго времени суток, что лучше выбрать для vk бота? Нужно учитывать, что бот будет очень часто...

7
Sergik
29.05.2007, 10:54 2
Лично я всегда одной пользуюсь. Вообще всегда лучше приводить БД как можно ближе к 3 нормальной форме, хотя с точки зрения программирования это увеличивает сложность кода.
Если две колонки новостей с разной информацией и две таблицы, то придеться выполнять два запроса к БД, а это почти всегда хуже (по производительности), чем один. Если важна скорость загрузки страницы, а обновление раз в неделю, то имеет смысл раз в неделю специальным скриптом формировать статические HTML файлы с новостями, а на странице подключать их через include file.
0 / 0 / 0
Регистрация: 23.05.2007
Сообщений: 236
29.05.2007, 12:46  [ТС] 3
А что такое 3 нормальная форма?
0
Sergik
29.05.2007, 15:46 4
третья нормальная форма требует, чтоюы все неключевые столбцы зависели от первичного ключа и не зависили друг от друга.
0 / 0 / 0
Регистрация: 23.05.2007
Сообщений: 236
29.05.2007, 17:12  [ТС] 5
А как связать 2 поля в 2-х таблицах (точнее чтобы одно поле и его значение введенное в первую табл, отображалось во второй)?
0
Sergik
29.05.2007, 17:47 6
пример 'Новости'.
Допустим есть три версии сайта: англ, немецкая и русская; естественно, что новости для разных версий разные.
Делаем две таблицы
1)Таблица LANG_TYPE

ID_LANG_TYPE
------------
NAME

2)Таблица NEWS

ID_NEWS
---------
ID_LANG_TYPE (foreign key из таблицы LANG_TYPE)
TITLE
BODY
NDATE

Вот вполне нормальная организация БД

>точнее чтобы одно поле и его значение введенное
>в первую табл, отображалось во второй

Как раз это и называется 'излишним дублированием данных' и этого надо избегать (если речь идет о физическом хранении одних данных в разных местах). Я обычно проектирую БД таким образом, что дублируются только различные ID (ID_LANG_TYPE в примере выше), т.к. без этого никуда ни деться и ничто кроме них не дублируется. Типы ID практически всегда IDENTITY (COUNTER)
0 / 0 / 0
Регистрация: 23.05.2007
Сообщений: 236
30.05.2007, 06:06  [ТС] 7
Т. е. Вы в ручную вводите данные (ID_LANG_TYPE) вначале в одну, а затем в другую таблицу или Вы связываете ID_LANG_TYPE в одной таблице с ID_LANG_TYPE в другой таблице, если так, то как это сделать? или я что-то не понял?
0
Sergik
30.05.2007, 11:17 8
Вручную заполняется таблица LANG_TYPE (1-англ, 2- немецкий, 3 - русский)
Затем выполняется SQL:
ALTER TABLE NEWS
ADD FOREIGN KEY (ID_LANG_TYPE)
REFERENCES LANG_TYPE
Теперь таблицы связаны между собой отношением один (ID_LANG_TYPE) ко многим (ID_NEWS). Это значит, что вы не сможете добавить запись в таблицу NEWS, если ID_LANG_TYPE не равен ни 1, ни 2, ни 3. Отдельно можно поговорить о значении NULL, по-умолчанию в таблицу NEWS можно вставить запись, где ID_LANG_TYPE = NULL, так как в этой конкретной задаче это не нужно (новость обязательно должна принадлежать к какой-то одной версии сайта), то ID_LANG_TYPE в таблице NEWS следует сделать NOT NULL.
Теперь о нормальных формах:
Расмотрим пример: клиенты сайта, все клиенты работают в какой-то из компаний, фирма-владелец сайта работает только с клиентами компаний.
1 н.ф. требует, чтобы таблица была прямоугольной и не содержала ячеек, включающих несколько значений.
К примеру, БД может содержать такую таблицу:
ID_COMPANY
----------
NAME_COMPANY
SOTRUDNIKI
CONTACT_PHONE
В этом случае в поле сотрудники будут перечислятся сотрудники компании-клиенты сайта, т.е. в одной ячейке содержатся несколько значений.
Если спроектировать таблицу иначе:
ID_COMPANY
----------
NAME_COMPANY
SOTRUDNIK_1
SOTRUDNIK_2
SOTRUDNIK_3
SOTRUDNIK_4
SOTRUDNIK_5
SOTRUDNIK_6
CONTACT_PHONE
то таблица перестает быть прямоугольной, т.к. в одной компании может быть как 1 клиент, так и 6.
Чтобы таблица удовлетворяла первой н.ф., ее нужно сделать (две таблицы), например, так:
ID_COMPANY
----------
NAME_COMPANY
CONTACT_PHONE

ID_SOTRUDNIK
---------
ID_COMPANY
в таком случае таблицы будут прямоугольными и содержать в ячейке только одно значение (с некоторыми ограничениями, например, мы предположили, что у компании может быть только один контактный телефон)
2 н.ф. требует, чтобы данные во всех неключевых столбцах зависели от ключевого столбца.
Введем понятие зависимости - поле зависит от другого поля, если по значению другого поля ожно однозначно определить знеачение зависимого поля.
Приведенные выше таблицы соответствуют 2 н.ф. Вот если бы мы использовали во второй таблице не ID_SOTRUDNIK, а NAME_SOTRUDNIK, то таблица соответствовала бы 1 н.ф., но не соответствовала бы второй, т.к. по имени сотрудника (являющимся ключем) нельзя определить ID_COMPANY, т.к. в разных компаниях могут быть сотрудники с одним и тем же именем.
3 н.ф. требует, чтобы все неключевые столбцы зависели от первичного ключа и не зависили друг от друга.
Добавим в таблицу ID_COMPANY поле CITY_COMPANY и PHONE_CODE_CITY (телефонный код города)
По значению ID_COMPANY можно однозначно определить все остальные поля, значит таблица удовлетворяет 2 н.ф. Но мы видим, что PHONE_CODE_CITY зависит от поля CITY_COMPANY,не являющимся ключевым (по городу можно узнать его телефонный код). Для того, чтобы привести пример к 3 н.ф. следует поступить так:
ID_COMPANY
----------
NAME_COMPANY
CONTACT_PHONE
ID_COMPANY_CITY

ID_SOTRUDNIK
---------
ID_COMPANY

ID_COMPANY_CITY
----------
NAME_CITY
PHONE_CODE_CITY

Общие рекомендации:
1) в каждой талице использовать поле ID, и делать его ключем и , желательно IDENTITY.
2) Если из таблицы подразумевается вывод нескольких значений или предполагается вставлять записи в 'середину' таблицы, то предусмотреть символьное поле порядок сортировки (если сортировка не может быть осуществлена по другому полю). Например список компаний можно выводить, сортируя по ее имени. А вот если брать форум, то сортировку нужно вводить явным образом, чтобы иметь возможность добавить запись между двумя записями (например есть запись с порядком сортировки 001 и вторая с 002, чтобы ответить на сообщение 001, требуется добавить запись с порядком сортировки, например, 001_001, тогда список
IT_Exp
Эксперт
87844 / 49110 / 22898
Регистрация: 17.06.2006
Сообщений: 92,604
30.05.2007, 11:17

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

Что использовать лучше, быстрее? OLEDB или Microsoft.Jet ?
Что использовать лучше, быстрее? OLEDB or Microsoft.Jet

Что лучше две видеокарты или одна
У меня на материнской плате два места для видеокарты но PCI-Express x16 2.0 я не знаю что луче...

Подскажите что лучше - одна видокарта, или две, объединенных в SLI или CrossFire, за ту же цену?
Доброго времени суток, подскажите что лучше, видеокарта за 15 000рублей, или же 2 видеокарты за 15...

Что лучше: две подобные таблицы или одна с дополнительным уточняющим столбцом?
В случае одной таблицы с дополнительным уточняющим столбцом этот столбец будет заполняться...


Искать еще темы с ответами

Или воспользуйтесь поиском по форуму:
8
Ответ Создать тему
Опции темы

КиберФорум - форум программистов, компьютерный форум, программирование
Powered by vBulletin® Version 3.8.9
Copyright ©2000 - 2021, vBulletin Solutions, Inc.