Сотни псевдонимов / синонимов против полностью определенных имен таблиц базы данных

Question

Учитывая сотни таблиц базы данных в нескольких схемах, при создании хранимых процедур и представлений вы бы порекомендовали использовать псевдонимы / синонимы или полное имя? Учитывая несколько schema.table вроде так,

Orders.OrderHeader, Production.LineThroughput, Sales.Opportunities

Я ожидаю небольшого прироста производительности с использованием квалифицированных имен, но если бы таблицу, такую ​​как Orders.Customers, пришлось бы переместить в Sales.Customers, мне пришлось бы либо изменить существующие представления / процедуры, ссылаясь на Orders.Customers, либо использовать синоним заранее, где ожидается такой шаг. Я вижу ценность в переносе кода в тестирование с использованием синонимов, но в то же время я мог бы также создать копию своей производственной среды для тестирования / dev и не требовать синонимов.

Электронная документация по SQL Server рекомендует всегда использовать полное имя. Некоторые друзья предлагают создать один синоним для каждой из сотен таблиц и использовать только синонимы. Хотя я предпочитаю использовать полностью определенное имя (более читаемый и не требующий пояснений код, зная, к какому объекту относится упомянутый объект, и привычку печатать schema.table), с каким значительным преимуществом в плане производительности, работы или удобства чтения (dis) вы заметили использование синонимов против полных имен таблиц?

Answer 1

Код (SQL или хранимый процесс) должен оставаться в системе управления исходным кодом за пределами базы данных.Если вы не можете выполнить точный поиск и замену, у вас есть серьезные проблемы, поэтому на самом деле это следует решить в первую очередь.

Если число таблиц велико, вам действительно нужно использовать префиксы.Не Sales.Customer, а REF_Customer.

Точка указывает, что она находится в отдельной базе данных (MS и Sybase) или схеме (DB2 и Oracle).Это отдельная единица восстановления, поэтому они поддерживаются отдельно, и сервер должен переключать контексты каждый раз, когда вы пересекаете границу.Поэтому вам необходимо правильно собирать таблицы и использовать несколько баз данных / схем, а не много.Например.разделите справочные таблицы, которые не обновляются часто, и на них часто ссылаются из других баз данных / схем.

Всегда используйте полностью определенные имена в коде SQL.Не в качестве префикса для имен столбцов, а в каждом предложении WHERE и FROM.Это очень поможет при перемещении базы данных / схем или сред, DEV в UAT или PROD.

Answer 2

Это ситуация "зависит".

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

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

С другой стороны, в некоторых случаях я предпочел написать код, который явно ссылается насхема - это был код для проекта переноса данных, который должен был ссылаться на одну и ту же таблицу в нескольких схемах, и мы «заблокировали» имена схем, чтобы они работали в DEV / TEST / etc, без необходимости большого количествасинонимы.

Answer 3

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

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

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

Если вам нужно переместить таблицу в другую базу данных, псевдонимы также полезны.Поскольку полное имя таблицы указывается в запросе только один раз, его легче изменить.

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

Answer 4

Мои два цента ...

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

По производительности, по крайней мере, в Oracle есть сообщения о небольшом падении производительности с помощью синонимов, поскольку база данных должна сначала разрешить имя синонима, а затем разрешить имя целевого объекта (таблица / представление / пакет / и т.д. .). Публичные синонимы имеют чуть больший удар по производительности (в 2 раза по сравнению с непубличными синонимами). Однако это несколько оспаривается; см. эту статью Ask Tom для получения дополнительной информации. Однако, если вы не доведите свою базу данных до предела, я бы об этом не беспокоился.

Answer 5

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

Схемы предназначены для изоляции пространства имен.Например, при разработке системы SaaS схемы могут использоваться очень эффективно для разделения проблем для нескольких арендаторов.Схемы также могут быть использованы для отделения теста от производства или данных одного приложения от другого.И это не только для таблиц, но и для хранимых процедур и всех других объектов базы данных.

DB2 предоставляет специальный регистр, называемый CURRENT SCHEMA, который позволяет кодировать неквалифицированные имена объектов, но переключаться на правильную схему, просто устанавливая CURRENT SCHEMAспециальный регистр вот так:

SET CURRENT SCHEMA =  'Production'

Это, на мой взгляд, гораздо лучший подход, чем использование синонимов.

Answer 6

, если вы ожидаете, что таблицы действительно будут перемещаться, будьте осторожны, используйте полные имена.