Этот баннер — требование Роскомнадзора для исполнения 152 ФЗ.
«На сайте осуществляется обработка файлов cookie, необходимых для работы сайта, а также для анализа использования сайта и улучшения предоставляемых сервисов с использованием метрической программы Яндекс.Метрика. Продолжая использовать сайт, вы даёте согласие с использованием данных технологий».
Политика конфиденциальности

Новые сообщения [новые:0]
Дайджест
Горячие темы
Избранное [новые:0]
Форумы
Пользователи
Статистика
Статистика нагрузки
Мод. лог
Поиск
|
|
15.07.2005, 18:01
|
|||
|---|---|---|---|
А зачем такая обектная ориентированность нужна? |
|||
|
#18+
Ну как в постгрисе. Наследование таблиц. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
15.07.2005, 20:18
|
|||
|---|---|---|---|
|
|||
А зачем такая обектная ориентированность нужна? |
|||
|
#18+
Подначить на лай фанатов ООП. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
18.09.2005, 21:51
|
|||
|---|---|---|---|
А зачем такая обектная ориентированность нужна? |
|||
|
#18+
Ладно, фиг с ними, с фанатами. Лучше рассмотреть возможность использования. Во многих случаях эта фича была бы полезной. Я имею в виду структуры данных. Вот, вопрос в другом: наследование поведения. Пусть в таблице - родителе будет триггер Tr1, рабатывающий на, скажем, изменение записи. Можно ли его переопределить в таблице - потомке? Есть ли, что-то вроде "Inherited" в теле триггера? (Т.е. возможность обратиться к базовому методу триггеру)? Как вообще (и в каком порядке) будет организовано выполнение триггеров таблицы - родителя и потомка? Есть ли возможность в базовом триггере определить контекст, в котором он вызван? (То ли данные изменены просто в базовой таблиц, то ли в потомке) Есть ли возможность узнать список изменяемых полей? По поводу наследования констреинтов также было бы интересно узанать. Было бы классно, если бы кто-нибудь рассказал про такие безобразия. Поделитесь знаниями, ... ГУРУ! ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
19.09.2005, 00:09
|
|||
|---|---|---|---|
|
|||
А зачем такая обектная ориентированность нужна? |
|||
|
#18+
великий RTFM и метод научного тыка вам в помощь!!! ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
19.09.2005, 00:25
|
|||
|---|---|---|---|
А зачем такая обектная ориентированность нужна? |
|||
|
#18+
vfabrвеликий RTFM и метод научного тыка вам в помощь!!! Это да, это нам завсегда не жалко Сам такой. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
19.09.2005, 10:20
|
|||
|---|---|---|---|
|
|||
А зачем такая обектная ориентированность нужна? |
|||
|
#18+
не я серьезно если интересно провинтилируйте этот вопрос и расскажите о результатах :-) ЗЫ гуру не рождаются ими становятся ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
19.09.2005, 11:13
|
|||
|---|---|---|---|
|
|||
А зачем такая обектная ориентированность нужна? |
|||
|
#18+
На самом деле неаследование в PG это некая фикция но порой полезная... т.е. выражения create table a( id integer) ; create table b (name text) inherits (a); select * from a; select * from a only; select * from b; физически эквивалентны cледующим: create table a( id integer) ; create table b (id integer, name text); select id from a union all select * from b; select * from a ; select * from b; т.е. от механизма наследования мы получаем возможность не повторять струткуру дочерних таблиц при описании , а также прозрачный метод добавления полей ( добавленное поле предка- автоматически добавится и у детей).. Ну и плюс возможность не писать сложных запросов с юнионами... Вот собственно и вся прелесть... Т.е. всем кто ждет от наследования чегото большего - тот ошибается... соотвественно ни индексы - ни триггеры не наследуются... ибо вставка в таблицу B - ни коим образом не затрагивает таблицу A b наоборот... но ведь вам ни кто не запрещает руками определять индексы и переназначать триггерные функции например с таблицы A на таблицу B? Просто вы будете делать это сами ... Вот... Еще одно применение наследования таблиц-это возможность в применением tablespace - разнести одну логическую таблицу на два разных диска.. например актуальные данные деражать в таблице A -старые данные держать в таблице B - а обращаться к данным как к таблице C create table A (ID integer,NAME text ) tablespace Disk1; create table B () inherits(A) tablespace Disk2; create table C () inherits(B) ; select * from C -получить все данные и актуальные и архивные... select * from A - только актуальные данные select * from B - только архивные... согласитесь - это удобнее чем писать сложные запросы с обьединением нескольких таблиц... Ну и естeственно констроль целостности типа форейн ключей тут не буцдет работать - т.е. придется контролировать все руками... Вот примерно сумбурно я рассказал что такое механизм наследования в PG.. Во всяком случае я его так понимаю.... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
19.09.2005, 11:41
|
|||
|---|---|---|---|
А зачем такая обектная ориентированность нужна? |
|||
|
#18+
наследуются констрайнты некоего вида. помнится типа чеков. Обычные триггеры не наследуются. Можно перекрывать сколько угодно. На вопрос о наследование ФК и т.п. кто-то давал указания на конкретные контрибы. Поскольку мне не понадобилось (уже все было сконструировано), то не проверял. Но посёчить по форуму имеет смысл. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|

start [/forum/topic.php?fid=53&mobile=1&tid=2007005]: |
0ms |
get settings: |
7ms |
get forum list: |
11ms |
check forum access: |
2ms |
check topic access: |
2ms |
track hit: |
59ms |
get topic data: |
6ms |
get forum data: |
1ms |
get page messages: |
23ms |
get tp. blocked users: |
1ms |
| others: | 259ms |
| total: | 371ms |

| 0 / 0 |
