Этот баннер — требование Роскомнадзора для исполнения 152 ФЗ.
«На сайте осуществляется обработка файлов cookie, необходимых для работы сайта, а также для анализа использования сайта и улучшения предоставляемых сервисов с использованием метрической программы Яндекс.Метрика. Продолжая использовать сайт, вы даёте согласие с использованием данных технологий».
Политика конфиденциальности
|
|
|
Множественное наследование VS домены/типы
|
|||
|---|---|---|---|
|
#18+
С Новым Годом, all! Всем хорош домен, одно плохо: нельзя динамически переопределить его тип. Команда ALTER DOMAIN (очередное разочарование) позволяет переопределять только дефолты и чеки. Как альтернативу при создании таблиц можно использовать множественное наследование от таблиц-"доменов", в которых определено буквально по одному-два поля. В случае необходимости можно переопределить тип поля в таблице-предке, и по всей БД это вызовет автоматическое изменение во всех таблицах-наследниках. Пример: Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. А теперь, собственно, вопрос: какие грабли нас ждут на этом пути . ЗЫ: советы тщательнее проектировать систему с самого начала, чтобы не иметь потом гиммора с переопределением доменов принимаются, но всерьез не рассматриваются. :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 02.01.2007, 10:57 |
|
||
|
Множественное наследование VS домены/типы
|
|||
|---|---|---|---|
|
#18+
Очевидные грабли: 1. Поля с разными именами, но одного домена? 2. В любом случае проблема обновления зависимых VIEW остается. Неочевидные - как скажется на производительности? И что мешает автоматизировать (если забить на проблему №2) изменение базового типа домена? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 02.01.2007, 18:45 |
|
||
|
Множественное наследование VS домены/типы
|
|||
|---|---|---|---|
|
#18+
1. Поля с разными именами, но одного домена? Да, есть такая проблема. В принципе можно наплодить доменотаблиц под каждое имя... Некрасиво, но вариант. Еще можно помусолить тему правильности (в смысле нормализации) наличия разных полей одного домена в таблице, но больно тема скользкая. автор2. В любом случае проблема обновления зависимых VIEW остается. В этом месте поподробнее, пожалуйста. авторНеочевидные - как скажется на производительности? Вот это-то и хотелось услышать от опытных пострессоров. Как оно вообще с наследованием, тормозит? (хотя с чего бы ему тормозить?) авторИ что мешает автоматизировать (если забить на проблему №2) изменение базового типа домена? Неизящно, брутфорс какой-то... :) Кстати, вот дополнительный вопрос: насколько оправдано использование безразмерных типов (varchar без длины и numeric без определения точности)? Как хранятся такие типы физически и т.п. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.01.2007, 14:40 |
|
||
|
Множественное наследование VS домены/типы
|
|||
|---|---|---|---|
|
#18+
Вадим Прудивус Кстати, вот дополнительный вопрос: насколько оправдано использование безразмерных типов (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 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.01.2007, 16:18 |
|
||
|
Множественное наследование VS домены/типы
|
|||
|---|---|---|---|
|
#18+
Вадим Прудивус[quot ]Как оно вообще с наследованием, тормозит? (хотя с чего бы ему тормозить?) Конечно, а как-же по другому? При запросе к парент-таблице по дефолту будут просматриваться все унаследованные таблицы. Т.е. Запрос эквивалентен UNION нескольких запросов к разным таблицам. Возможно, я не уверен, в случае наследования, может сначала выполняться чтение и объединение, а затем уже применение условия WHERE. Механизм Constraint exclusion можно реализовать введя идентификатор класса в парент таблицу, но он во-первых может оказаться бесполезным, т.к. условие CHECK обычно накладывается не на те поля по которым требуется делать разнообразные выборки, во-вторых он будет накладывать дополнительную нагрузку т.к. будут проверяться чеки для всех унаследованных таблиц без исключения. Для больших таблиц документация рекомендует применять наследование для ускорения запросов, но использует при этом понятие "разделение таблиц", т.е. партиционирование (наследники полностью эквивалентны по структуре паренту). Других полезных применений наследования и чтобы при этом не тормозило, документация не называет. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.09.2008, 14:42 |
|
||
|
|

start [/forum/topic.php?fid=53&tid=2004014]: |
0ms |
get settings: |
6ms |
get forum list: |
18ms |
check forum access: |
4ms |
check topic access: |
4ms |
track hit: |
42ms |
get topic data: |
13ms |
get forum data: |
4ms |
get page messages: |
65ms |
get tp. blocked users: |
3ms |
| others: | 225ms |
| total: | 384ms |

| 0 / 0 |
