Обьектно Ориентированная БД

[Crazy]

Автор оригинала: NEK
Моему классу все равно таблицы из одной базы из разных - не имеет значения. Мой класс - это класс для работы с таблицой, а не с базой.

Т.е. работу с ГРУППАМИ таблиц твой класс вообще не поддерживает?

 

[NEK]

Да

 

[Crazy]

Понятно. Более вопросов не имею.

 

[Alexandre]

NEK - т.е. как я понял изобретаем хитрый импорт/экспорт из БД в массив и обратно....
если связность маленькая - то можно попробовать...а если больше 2х таблиц - то SQL изобретаем...
а если в таблицах имеются столбцы с одинаковыми наименованиями??? - приведи пример такого запроса
а если необходимо выбрать только двойные значения полей (т.е. повторяющиеся строки по одному наименованию)....
и таких жизненных примеров куча
что скажешь?

 

[tony2001]

>>Т.е. работу с ГРУППАМИ таблиц твой класс вообще не поддерживает?
>Да

для справки:
получившийся велосипед с половиной колеса можно будет использовать только до того, как ты узнаешь о JOIN.

 

[Demiurg]

Дмитрий нумбер два.

 

[Sad Spirit]

Автор оригинала: Demiurg
Дмитрий нумбер два.

Не обижайте Дмитрия, тот хоть писал относительно грамотно и понятно.

 

[tony2001]

однако, по полезности "супер-проектов" они похожи однозначно...

 

[YRusinov]

Супер-проекты живут, пока ими занимаются авторы, как только автор перестает заниматься проектом, он умирает.

 

[Screjet]

NEK
Я тебя поддерживаю, помогу чем смогу. Открывай в оффтопе тему, выкладывай код, будем проводить обчественный аудит. Для примера вот что удобно было бы:

//враппер первого уровня (class db):
$this->statment_pool['My_Table'] = new db_statment( $sql_query );
//враппер Query_Tool, который инстансирует db
$this->db = new db( $options );
//основной класс, который наследует Query_Tool
$this->My_Table['Field_Name'];
//или так, для "хитрых" запросов
$this->My_Container['Field_Name'];

 

[Anton]

Народ! Вы че?? Тред-то по объектным БД, а не про слои абстракции от БД.

 

[tony2001]

>Тред-то по объектным БД, а не про слои абстракции от БД
ну наконец-то хоть кто-то заметил...

 

[Alexandre]

кто завел тред, тот и заметил
но Абстракция БД очень схожа с Объектным подходом (там тоже абстракция )

 

[makRo]

Одна из основных фич объектного подхода работы с данными - это возможность работы с данными разного типа (SQL, XML, CVS, etc...)
А это уже не просто удобно - это очень удобно (!), при условии, что это универсально.
Исследую этот вопрос в Java, полезные достижения можно перенести в PHP..

 

[Crazy]

makRo, как ты представляешь себе унифицированный интерфейс к SQL (реляционные структуры), XML (иерархические и сетевые структуры) и CVS (направленный граф версий)? Что-то мне ничего здравого в голову не приходит.

 

[makRo]

Crazy, хотя бы ADO мелкомягких)

P.S. там очепятка, вместо CVS -> CSV

 

[Crazy]

ADO реализует исключительно реляционную модель. Стало быть, работа с XML через такой интерфейс ПРИНЦИПИАЛЬНО неэффективна.

 

[makRo]

возможно,
но это не повод не стремится к удобству (в абстракции, и если этого требует поставленная задача)

 

[Crazy]

Переходя к ТАКОМУ унифицированному интерфейсу ты удобство УНИЧТОЖАЕШЬ. Работать с иерархическими данными через реляционный интерфейс -- все равно, что лечь в клинику, чтобы там "привили" геморрой.

Обобщенный враппер имеет смысл в тех случаях, когда есть, что обобщать. Тот же ADO сделан для того, чтобы дать унифициованный реляционный интерфейс к различным реляционным же СУБД -- в этом есть смысл.

 

[Crazy]

Автор оригинала: makRo
и если этого требует поставленная задача

Что до прикладных задач, то часто можно сформулировать прикладной уровень доступа к данным (facade pattern), который уже реализуется поверх sql, xml и т.п. Но, что принципиально важно, этот интерфейс специфичен для конкретного приложения, не более того.