powered by simpleCommunicator - 2.0.60     © 2026 Programmizd 02
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Форумы / PostgreSQL [игнор отключен] [закрыт для гостей] / Множественное наследование VS домены/типы
5 сообщений из 5, страница 1 из 1
Множественное наследование VS домены/типы
    #34234680
Вадим Прудивус
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
С Новым Годом, all!

Всем хорош домен, одно плохо: нельзя динамически переопределить его тип. Команда ALTER DOMAIN (очередное разочарование) позволяет переопределять только дефолты и чеки. Как альтернативу при создании таблиц можно использовать множественное наследование от таблиц-"доменов", в которых определено буквально по одному-два поля. В случае необходимости можно переопределить тип поля в таблице-предке, и по всей БД это вызовет автоматическое изменение во всех таблицах-наследниках.

Пример:

Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
CREATE TABLE "Domains"."Quantity" (
  "Quantity" NUMERIC DEFAULT  0 
) WITHOUT OIDS;

CREATE TABLE "Domains"."Amount" (
  "Amount" NUMERIC( 9 , 2 ) DEFAULT  0 
) WITHOUT OIDS;

CREATE TABLE "public"."table1" (
  "id" SERIAL, 
  CONSTRAINT "table1_pkey" PRIMARY KEY("id")
) INHERITS ("Domains"."Amount", "Domains"."Quantity")
WITHOUT OIDS;

А теперь, собственно, вопрос: какие грабли нас ждут на этом пути .

ЗЫ: советы тщательнее проектировать систему с самого начала, чтобы не иметь потом гиммора с переопределением доменов принимаются, но всерьез не рассматриваются. :)
...
Рейтинг: 0 / 0
Множественное наследование VS домены/типы
    #34235068
.gc
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
.gc
Гость
Очевидные грабли:
1. Поля с разными именами, но одного домена?
2. В любом случае проблема обновления зависимых VIEW остается.

Неочевидные - как скажется на производительности?

И что мешает автоматизировать (если забить на проблему №2) изменение базового типа домена?
...
Рейтинг: 0 / 0
Множественное наследование VS домены/типы
    #34235723
Вадим Прудивус
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
1. Поля с разными именами, но одного домена?
Да, есть такая проблема. В принципе можно наплодить доменотаблиц под каждое имя... Некрасиво, но вариант. Еще можно помусолить тему правильности (в смысле нормализации) наличия разных полей одного домена в таблице, но больно тема скользкая.

автор2. В любом случае проблема обновления зависимых VIEW остается.
В этом месте поподробнее, пожалуйста.

авторНеочевидные - как скажется на производительности?
Вот это-то и хотелось услышать от опытных пострессоров. Как оно вообще с наследованием, тормозит? (хотя с чего бы ему тормозить?)

авторИ что мешает автоматизировать (если забить на проблему №2) изменение базового типа домена?
Неизящно, брутфорс какой-то... :)

Кстати, вот дополнительный вопрос: насколько оправдано использование безразмерных типов (varchar без длины и numeric без определения точности)? Как хранятся такие типы физически и т.п.
...
Рейтинг: 0 / 0
Множественное наследование VS домены/типы
    #34235856
Jelis
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Вадим Прудивус
Кстати, вот дополнительный вопрос: насколько оправдано использование безразмерных типов (varchar без длины и numeric без определения точности)? Как хранятся такие типы физически и т.п.


С точки зрения занимаемого пространства - одинаково. "слово" и в varchar(100) и в varchar будет занимать одинаково. С numeric - аналогично. По производительности тоже одинаково. Единственное, с точки зрения логической структуры бд, имно, лучше лимиты ставить. А то если вдруг фамилия будет 3000 знаков - могут быть проблеммы :-)

http://www.postgresql.org/docs/8.1/interactive/datatype.html#DATATYPE-NUMERIC-DECIMAL
http://www.postgresql.org/docs/8.1/interactive/datatype-character.html
...
Рейтинг: 0 / 0
Период между сообщениями больше года.
Множественное наследование VS домены/типы
    #35567705
MySQLCraft
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Вадим Прудивус[quot ]Как оно вообще с наследованием, тормозит? (хотя с чего бы ему тормозить?)
Конечно, а как-же по другому? При запросе к парент-таблице по дефолту будут просматриваться все унаследованные таблицы. Т.е. Запрос эквивалентен UNION нескольких запросов к разным таблицам. Возможно, я не уверен, в случае наследования, может сначала выполняться чтение и объединение, а затем уже применение условия WHERE. Механизм Constraint exclusion можно реализовать введя идентификатор класса в парент таблицу, но он во-первых может оказаться бесполезным, т.к. условие CHECK обычно накладывается не на те поля по которым требуется делать разнообразные выборки, во-вторых он будет накладывать дополнительную нагрузку т.к. будут проверяться чеки для всех унаследованных таблиц без исключения. Для больших таблиц документация рекомендует применять наследование для ускорения запросов, но использует при этом понятие "разделение таблиц", т.е. партиционирование (наследники полностью эквивалентны по структуре паренту). Других полезных применений наследования и чтобы при этом не тормозило, документация не называет.
...
Рейтинг: 0 / 0
5 сообщений из 5, страница 1 из 1
Форумы / PostgreSQL [игнор отключен] [закрыт для гостей] / Множественное наследование VS домены/типы
Найденые пользователи ...
Разблокировать пользователей ...
Читали форум (0):
Пользователи онлайн (0):
x
x
Закрыть


Просмотр
0 / 0
Close
Debug Console [Select Text]