Гость
Целевая тема:
Создать новую тему:
Автор:
Форумы / PostgreSQL [игнор отключен] [закрыт для гостей] / Множественное наследование VS домены/типы / 5 сообщений из 5, страница 1 из 1
02.01.2007, 10:57
    #34234680
Вадим Прудивус
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Множественное наследование VS домены/типы
С Новым Годом, 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
02.01.2007, 18:45
    #34235068
.gc
.gc
Гость
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Множественное наследование VS домены/типы
Очевидные грабли:
1. Поля с разными именами, но одного домена?
2. В любом случае проблема обновления зависимых VIEW остается.

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

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

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

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

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

Кстати, вот дополнительный вопрос: насколько оправдано использование безразмерных типов (varchar без длины и numeric без определения точности)? Как хранятся такие типы физически и т.п.
...
Рейтинг: 0 / 0
03.01.2007, 16:18
    #34235856
Jelis
Гость
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Множественное наследование VS домены/типы
Вадим Прудивус
Кстати, вот дополнительный вопрос: насколько оправдано использование безразмерных типов (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
Период между сообщениями больше года.
30.09.2008, 14:42
    #35567705
MySQLCraft
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Множественное наследование VS домены/типы
Вадим Прудивус[quot ]Как оно вообще с наследованием, тормозит? (хотя с чего бы ему тормозить?)
Конечно, а как-же по другому? При запросе к парент-таблице по дефолту будут просматриваться все унаследованные таблицы. Т.е. Запрос эквивалентен UNION нескольких запросов к разным таблицам. Возможно, я не уверен, в случае наследования, может сначала выполняться чтение и объединение, а затем уже применение условия WHERE. Механизм Constraint exclusion можно реализовать введя идентификатор класса в парент таблицу, но он во-первых может оказаться бесполезным, т.к. условие CHECK обычно накладывается не на те поля по которым требуется делать разнообразные выборки, во-вторых он будет накладывать дополнительную нагрузку т.к. будут проверяться чеки для всех унаследованных таблиц без исключения. Для больших таблиц документация рекомендует применять наследование для ускорения запросов, но использует при этом понятие "разделение таблиц", т.е. партиционирование (наследники полностью эквивалентны по структуре паренту). Других полезных применений наследования и чтобы при этом не тормозило, документация не называет.
...
Рейтинг: 0 / 0
Форумы / PostgreSQL [игнор отключен] [закрыт для гостей] / Множественное наследование VS домены/типы / 5 сообщений из 5, страница 1 из 1
Найденые пользователи ...
Разблокировать пользователей ...
Читали форум (0):
Пользователи онлайн (0):
x
x
Закрыть


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