2010-03-10 2 views
1

Когда я создаю представление, я могу создать его на нескольких столбцах из разных таблиц. Когда я хочу создать таблицу поиска, мне нужна информация из одной таблицы, например, внешнего ключа таблицы заказов, чтобы получить детали клиента из другой таблицы. Я могу создать представление с параметрами, чтобы убедиться, что он получит все данные, которые мне нужны. Я также мог - из того, что я читал, - составить таблицу поиска. В чем разница в этом случае и когда следует выбирать для таблицы поиска? Надеюсь, это не плохой вопрос, я пока не совсем в db;).Разница между представлением db и поисковым окном

ответ

2

Я думаю, что ваше использование «Lookup Table» немного слабое. В обычном языке таблица поиска - это таблица кода или справочных данных. Он может состоять из КОДА, ОПИСАНИЯ или расширения кода. Целью таких таблиц является предоставление разрешенных значений для ограниченных столбцов, таких как CUSTOMER_TYPE или PRIORITY_CODE. Эту категорию таблицы часто называют «постоянными данными», потому что она изменяется очень редко, если вообще. Значение определения этих данных в таблицах Lookup заключается в том, что они могут использоваться в внешних ключах и заполнять Dropdowns и Lists Of Values.

То, что вы описываете, это немного другой сценарий:

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

Обе эти таблицы представляют собой таблицы данных приложения. Записи клиентов и заказов являются динамическими. Теперь очевидно, что для получения дополнительных данных из таблицы Customer, чтобы отобразить вдоль данных заказа данные, и, в этом смысле, Клиент является «поисковой таблицей».Более уместно это родительская таблица, потому что у нее есть первичный ключ, на который ссылается внешний ключ по заказу.

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

2

Создание представления дает вам «живое» представление данных, как оно есть во время запроса. Это связано с более высокой нагрузкой на сервер, поскольку оно должно определять значения для каждого запроса. Это может быть дорогостоящим, в зависимости от размеров таблицы, реализаций баз данных и сложности определения вида.

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

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

+0

Итак, в таблице поиска вы не найдете отображение данных в реальном времени? Как эта таблица заполняется вручную? Вы имеете в виду, что каждый день вы будете запускать что-то вроде хранимой процедуры, чтобы обновить таблицу поиска, чтобы она оставалась актуальной? – Younes

+0

@Younes - на ваш вопрос о представлении против таблицы поиска, да, таблица поиска не будет содержать «живых» данных (обязательно), и вам нужно будет каким-то образом поддерживать данные таблицы (либо по регулярному расписанию, либо в качестве источника изменения информации). Представление представляет собой, в смысле, динамическую таблицу поиска. –

0

Вот пример таблицы перекодировки. У нас есть система, которая отслеживает Jurors, одна из таблиц JurorStatus. Эта таблица содержит все допустимые StatusCodes для присяжных заседателей:

Код: Значение
WS: Послужит
PP: Отложено
EM: Извините Military
IF: Ineligible Felon

Это таблица поиска для действительные коды.

Вид похож на запрос.

0

Просто научитесь писать sql-запросы, чтобы получить именно то, что вам нужно. Нет необходимости создавать представление! Представления не подходят для использования во многих случаях, особенно если вы начинаете основывать их на других представлениях, когда они будут убивать производительность. Не используйте представления так же, как сокращение для написания запроса.

 Смежные вопросы

  • Нет связанных вопросов^_^