Thread: Объектная модель данных
Здравствуйте!
Есть ли в Postgres объектная модель данных?
Аналог ООП в языках программирования.
Где об этом можно почитать?
Спасибо.
Объектной модели нет (пример объектной СУБД -- Cache http://en.wikipedia.org/wiki/Cach%C3%A9_(software) ) Есть так называемая объектно-реляционная. Статья для понимания: http://citforum.ru/database/articles/ordbms10/ (суть раскрыта в 4й и 5й частях). Правда, статья рассчитана на понимающего теорию (Кодда, Дейта и пр.) читателя. Вкратце смысл в том, что объекты СУБД (строки, таблицы, типы данных) имеют _некоторые_ черты объектов из ООП. Что касается Постгреса -- всё в документации http://www.postgresql.org/docs/9.0/static/ 2011/2/24 simplevolk <simplevolk@gmail.com>: > Здравствуйте! > Есть ли в Postgres объектная модель данных? > Аналог ООП в языках программирования. > Где об этом можно почитать? > Спасибо.
Приветствую,
--
// Dmitriy.
24 февраля 2011 г. 20:49 пользователь simplevolk <simplevolk@gmail.com> написал:
Здравствуйте!Есть ли в Postgres объектная модель данных?
ER-модель, которая отражает концепции проекта - всегда объектная.
Есть классы (таблица(-ы)), есть объекты (entity) - это строки в них и
если связи (relationship) между классами. В PostgreSQL возможно
явно вызарить связи "has a" (внешними ключами) и "is a"
(наследованием). Хотя последний тип (наследование) весьма
сомнительно в том плане, что способов реализации наследования
на физическом уровне в БД множество, а не только посредством
разделения на таблицы (можно хранить объекты классов одной
иерархии в какой-то одной таблице, например).
Кроме того (что самое существенное), выражать полиморфное
поведение Постгрес не позволяет. Хаки, подобные тем, что
применяются в Си чтобы писать (лет по десять :-)
объектно-ориентированные программки в расчёт не принимать :-)
Итого: выразить концепции проекта в виде классов и связей между
ними можно - это просто разработка ER-модели. Определить
полиморфные типы - то есть фундаментальный смысл
ОО-проектирования непосредственно нельзя (можно, как в Си,
но это того не стоит :-)
Есть классы (таблица(-ы)), есть объекты (entity) - это строки в них и
если связи (relationship) между классами. В PostgreSQL возможно
явно вызарить связи "has a" (внешними ключами) и "is a"
(наследованием). Хотя последний тип (наследование) весьма
сомнительно в том плане, что способов реализации наследования
на физическом уровне в БД множество, а не только посредством
разделения на таблицы (можно хранить объекты классов одной
иерархии в какой-то одной таблице, например).
Кроме того (что самое существенное), выражать полиморфное
поведение Постгрес не позволяет. Хаки, подобные тем, что
применяются в Си чтобы писать (лет по десять :-)
объектно-ориентированные программки в расчёт не принимать :-)
Итого: выразить концепции проекта в виде классов и связей между
ними можно - это просто разработка ER-модели. Определить
полиморфные типы - то есть фундаментальный смысл
ОО-проектирования непосредственно нельзя (можно, как в Си,
но это того не стоит :-)
Аналог ООП в языках программирования.Где об этом можно почитать?Спасибо.
--
// Dmitriy.
Re: [pgsql-ru-general] Re: [pgsql-ru-general] Объектная модель данных
From
"Andrey N. Oktyabrski"
Date:
On 02/24/11 22:40, Dmitriy Igrishin wrote: > Итого: выразить концепции проекта в виде классов и связей между > ними можно - это просто разработка ER-модели. Определить > полиморфные типы - то есть фундаментальный смысл > ОО-проектирования непосредственно нельзя (можно, как в Си, > но это того не стоит :-) Что понимается под "непосредственно" и под "как в Си"?
Re: [pgsql-ru-general] Re: [pgsql-ru-general] Re: [pgsql-ru-general] Объектная модель данных
From
Dmitriy Igrishin
Date:
25 февраля 2011 г. 11:11 пользователь Andrey N. Oktyabrski <ano@bestmx.ru> написал:
On 02/24/11 22:40, Dmitriy Igrishin wrote:Что понимается под "непосредственно" и под "как в Си"?Итого: выразить концепции проекта в виде классов и связей между
ними можно - это просто разработка ER-модели. Определить
полиморфные типы - то есть фундаментальный смысл
ОО-проектирования непосредственно нельзя (можно, как в Си,
но это того не стоит :-)
Под "непосредственностью" здесь понимается использование средств,
которые делают использование стиля ОО-проектирования
удобным (простым, надежным и эффективным). Если же для выражения
этого стиля (написания программы) при использовании той или иной
платформы (или языка) требуются чрезмерные усилия либо
мастерство, то такая платформа (язык) не позволяет произвести
такое выражение непосредственно, а значит, просто не поддреживает
технику ОО-проектирования/программирования.
На Си можно написать ОО-программу, но это неоправдано сложно,
потому что этот язык не поддерживает соответствующую технику
непосредственно. Чтобы лучше понять, что я имею в виду,
просмотрите эту статью, например
http://www.planetpdf.com/codecuts/pdfs/ooc.pdf
Лично я пускаю крокодилью слезу, когда думаю о тех, кто
пишет ОО-программы упомянутым как в статье образом, но
искренне жаль тех, кто потом такие программы сопровождает :-)
которые делают использование стиля ОО-проектирования
удобным (простым, надежным и эффективным). Если же для выражения
этого стиля (написания программы) при использовании той или иной
платформы (или языка) требуются чрезмерные усилия либо
мастерство, то такая платформа (язык) не позволяет произвести
такое выражение непосредственно, а значит, просто не поддреживает
технику ОО-проектирования/программирования.
На Си можно написать ОО-программу, но это неоправдано сложно,
потому что этот язык не поддерживает соответствующую технику
непосредственно. Чтобы лучше понять, что я имею в виду,
просмотрите эту статью, например
http://www.planetpdf.com/codecuts/pdfs/ooc.pdf
Лично я пускаю крокодилью слезу, когда думаю о тех, кто
пишет ОО-программы упомянутым как в статье образом, но
искренне жаль тех, кто потом такие программы сопровождает :-)
--
Sent via pgsql-ru-general mailing list (pgsql-ru-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-ru-general
--
// Dmitriy.
On 02/25/11 12:02, Dmitriy Igrishin wrote: > Итого: выразить концепции проекта в виде классов и связей между > ними можно - это просто разработка ER-модели. Определить > полиморфные типы - то есть фундаментальный смысл > ОО-проектирования непосредственно нельзя (можно, как в Си, > но это того не стоит :-) > > Что понимается под "непосредственно" и под "как в Си"? > > Под "непосредственностью" здесь понимается использование средств, > которые делают использование стиля ОО-проектирования > удобным (простым, надежным и эффективным). Если же для выражения > этого стиля (написания программы) при использовании той или иной > платформы (или языка) требуются чрезмерные усилия либо > мастерство, то такая платформа (язык) не позволяет произвести > такое выражение непосредственно, а значит, просто не поддреживает > технику ОО-проектирования/программирования. Пример: create table A (id int, name text); create table B (txt text) inherits A; select id, name from A; Выбраны все записи как из A, так и из B. Чего тут сложного-то? Никаких чрезмерных усилий :-) Или это не о том?
25 февраля 2011 г. 12:52 пользователь Andrey N. Oktyabrski <ano@bestmx.ru> написал:
Что касается понятия наследования, реализованного вOn 02/25/11 12:02, Dmitriy Igrishin wrote:Пример:Итого: выразить концепции проекта в виде классов и связей между
ними можно - это просто разработка ER-модели. Определить
полиморфные типы - то есть фундаментальный смысл
ОО-проектирования непосредственно нельзя (можно, как в Си,
но это того не стоит :-)
Что понимается под "непосредственно" и под "как в Си"?
Под "непосредственностью" здесь понимается использование средств,
которые делают использование стиля ОО-проектирования
удобным (простым, надежным и эффективным). Если же для выражения
этого стиля (написания программы) при использовании той или иной
платформы (или языка) требуются чрезмерные усилия либо
мастерство, то такая платформа (язык) не позволяет произвести
такое выражение непосредственно, а значит, просто не поддреживает
технику ОО-проектирования/программирования.
create table A (id int, name text);
create table B (txt text) inherits A;
select id, name from A;
Выбраны все записи как из A, так и из B. Чего тут сложного-то? Никаких чрезмерных усилий :-)
Или это не о том?
Пример является надуманным. Даже имена выбраны так, что понять
их предназначение невозможно.
На практике же, когда анализ предметной области выявляет концепции
проекта, следующим шагом после установления связей между ними,
является определение операций над этими концепциями. И если две
концепции связаны наследованием, то последнее не очень полезно
без полиморфизма.
Так вот определить полиморфные операции непосредственно в
PostgreSQL (в том же PL/pgSQL) невозможно. Возможно только
прилагая большую сообразительность и мастерство.
их предназначение невозможно.
На практике же, когда анализ предметной области выявляет концепции
проекта, следующим шагом после установления связей между ними,
является определение операций над этими концепциями. И если две
концепции связаны наследованием, то последнее не очень полезно
без полиморфизма.
Так вот определить полиморфные операции непосредственно в
PostgreSQL (в том же PL/pgSQL) невозможно. Возможно только
прилагая большую сообразительность и мастерство.
PostgreSQL (INHERITANCE clause). Принимая в расчёт ограничения,
указанные в
Разве что только для выборки из всех таблиц, олицетворяющих
производные классы, через таблицу, представляющую базовый класс
для них? Принимая
--
// Dmitriy.
25 февраля 2011 г. 15:03 пользователь Dmitriy Igrishin <dmitigr@gmail.com> написал:
PostgreSQL (INHERITANCE clause). Принимая в расчёт ограничения,
указанные в п. 5.8.1, я вообще не понимаю зачем этот функционал был
добавлен в PostgreSQL? Разве что только для выборки из всех таблиц,
олицетворяющих производные классы, через таблицу, представляющую
базовый класс (как в примере выше)? :-)
25 февраля 2011 г. 12:52 пользователь Andrey N. Oktyabrski <ano@bestmx.ru> написал:On 02/25/11 12:02, Dmitriy Igrishin wrote:Пример:Итого: выразить концепции проекта в виде классов и связей между
ними можно - это просто разработка ER-модели. Определить
полиморфные типы - то есть фундаментальный смысл
ОО-проектирования непосредственно нельзя (можно, как в Си,
но это того не стоит :-)
Что понимается под "непосредственно" и под "как в Си"?
Под "непосредственностью" здесь понимается использование средств,
которые делают использование стиля ОО-проектирования
удобным (простым, надежным и эффективным). Если же для выражения
этого стиля (написания программы) при использовании той или иной
платформы (или языка) требуются чрезмерные усилия либо
мастерство, то такая платформа (язык) не позволяет произвести
такое выражение непосредственно, а значит, просто не поддреживает
технику ОО-проектирования/программирования.
create table A (id int, name text);
create table B (txt text) inherits A;
select id, name from A;
Выбраны все записи как из A, так и из B. Чего тут сложного-то? Никаких чрезмерных усилий :-)
Или это не о том?
Пример является надуманным. Даже имена выбраны так, что понять
их предназначение невозможно.
На практике же, когда анализ предметной области выявляет концепции
проекта, следующим шагом после установления связей между ними,
является определение операций над этими концепциями. И если две
концепции связаны наследованием, то последнее не очень полезно
без полиморфизма.
Так вот определить полиморфные операции непосредственно в
PostgreSQL (в том же PL/pgSQL) невозможно. Возможно только
прилагая большую сообразительность и мастерство.
Что касается понятия наследования, реализованного вих предназначение невозможно.
На практике же, когда анализ предметной области выявляет концепции
проекта, следующим шагом после установления связей между ними,
является определение операций над этими концепциями. И если две
концепции связаны наследованием, то последнее не очень полезно
без полиморфизма.
Так вот определить полиморфные операции непосредственно в
PostgreSQL (в том же PL/pgSQL) невозможно. Возможно только
прилагая большую сообразительность и мастерство.
PostgreSQL (INHERITANCE clause). Принимая в расчёт ограничения,
указанные в п. 5.8.1, я вообще не понимаю зачем этот функционал был
добавлен в PostgreSQL? Разве что только для выборки из всех таблиц,
олицетворяющих производные классы, через таблицу, представляющую
базовый класс (как в примере выше)? :-)
--
// Dmitriy.
--
// Dmitriy.
On 02/25/11 15:06, Dmitriy Igrishin wrote: > Пример: > create table A (id int, name text); > create table B (txt text) inherits A; > > select id, name from A; > > Выбраны все записи как из A, так и из B. Чего тут сложного-то? > Никаких чрезмерных усилий :-) > > Или это не о том? > > Пример является надуманным. Даже имена выбраны так, что понять > их предназначение невозможно. Естественно, я не буду приводить тут примеры из реальных приложений. Они занимают слишком много места. > На практике же, когда анализ предметной области выявляет концепции > проекта, следующим шагом после установления связей между ними, > является определение операций над этими концепциями. И если две > концепции связаны наследованием, то последнее не очень полезно > без полиморфизма. И он есть, как показал мой надуманный пример. Как минимум, для операции select над концепциями A & B :-) > Так вот определить полиморфные операции непосредственно в > PostgreSQL (в том же PL/pgSQL) невозможно. Возможно только > прилагая большую сообразительность и мастерство. Не, мы всё-таки о разных вещах. Я о том, что операций над данными только четыре штуки - select, insert, update, delete. > Что касается понятия наследования, реализованного в > PostgreSQL (INHERITANCE clause). Принимая в расчёт ограничения, > указанные в п. 5.8.1, я вообще не понимаю зачем этот функционал был > добавлен в PostgreSQL? Разве что только для выборки из всех таблиц, > олицетворяющих производные классы, через таблицу, представляющую > базовый класс (как в примере выше)? :-) Почему только выборки? UPDATE/DELETE тоже.
25 февраля 2011 г. 17:23 пользователь Andrey N. Oktyabrski <ano@bestmx.ru> написал:
On 02/25/11 15:06, Dmitriy Igrishin wrote:Естественно, я не буду приводить тут примеры из реальных приложений. Они занимают слишком много места.Пример:
create table A (id int, name text);
create table B (txt text) inherits A;
select id, name from A;
Выбраны все записи как из A, так и из B. Чего тут сложного-то?
Никаких чрезмерных усилий :-)
Или это не о том?
Пример является надуманным. Даже имена выбраны так, что понять
их предназначение невозможно.И он есть, как показал мой надуманный пример. Как минимум, для операции select над концепциями A & B :-)На практике же, когда анализ предметной области выявляет концепции
проекта, следующим шагом после установления связей между ними,
является определение операций над этими концепциями. И если две
концепции связаны наследованием, то последнее не очень полезно
без полиморфизма.Не, мы всё-таки о разных вещах. Я о том, что операций над данными только четыре штуки - select, insert, update, delete.Так вот определить полиморфные операции непосредственно в
PostgreSQL (в том же PL/pgSQL) невозможно. Возможно только
прилагая большую сообразительность и мастерство.Почему только выборки? UPDATE/DELETE тоже.Что касается понятия наследования, реализованного в
PostgreSQL (INHERITANCE clause). Принимая в расчёт ограничения,
указанные в п. 5.8.1, я вообще не понимаю зачем этот функционал был
добавлен в PostgreSQL? Разве что только для выборки из всех таблиц,
олицетворяющих производные классы, через таблицу, представляющую
базовый класс (как в примере выше)? :-)
SELECT - это не операция, присущая концепциям, а средство
выборки сущностей концепций (т.е. объектов классов) по определённым
условиям.
Операции манипуляции с данными не дают даже малейшего
представления о том, что можно сделать с проектными понятиями,
то есть они являются лишь конструкциями SQL для создания новых и
изменения существующих объектов.
--
// Dmitriy.
On 02/25/11 17:38, Dmitriy Igrishin wrote: > SELECT - это не операция, присущая концепциям, а средство > выборки сущностей концепций (т.е. объектов классов) по определённым > условиям. > Операции манипуляции с данными не дают даже малейшего > представления о том, что можно сделать с проектными понятиями, > то есть они являются лишь конструкциями SQL для создания новых и > изменения существующих объектов. Вас понял. Теоретизировать нет ни малейшего желания. Вопросов больше нет.