И главное чего у вас не будет при таком подходе - подстановки смысловых значений отношения. Вы можете выкатить кортеж целиком как это делается в фориче выше, но не можете выбрать из него один произвольный элемент который отражает смысл кортежа в целом.

Нет в DDL такой фичи. Отсюда вопрос: кто нам запрещает обзавестись своей собственной схемой, которая в свою очередь такая же обыкновенная таблица, которую можно редактировать обыкновенным путем через тот же самый интерфейс, в которой и будет храниться все что надобно для счастья.

Заводим себе таблицу _relations с перечисленными выше полями и еще добавляем одно. Которое указывает на смысл отношения. Тогда не собирая кортежей можно заменить значения связанного поля по отношениям на значения смыслового поля. Вместо циферок индексов парент-чилд вы получите нормальный, человеко-читаемый список. Типичный option в текстовой ноде которого текст для человека, а value - для машины.

Ходим дальше. Кто запрещает завести свою таблицу _columns? В которой завести такие поля как transform и transform_options. PMA видели? Оно там называется browser transformation. В сиротском DDL можно сказать BLOB, а что значит этот BLOB - член влоб - никто не узнает никогда. Опять за десятилетия народ не удосужился потребовать MIME Type для блобов. В модельках шмалил.

ANSI горшки не обжигает? Ну поставьте ему свечку.

Заведя таблицу колонок получаем изумительную фичу. Любое поле можно объявить hidden и запрос сам выкинет это поле из SELECT. Сбылась мечта идиотов. Добавляем колонку column_alias. Теперь вместо дебильных карт в подвалах моделей у нас доступ к человеческим именам полей через парадный вход. Зашел в одминку и написал что отныне поле prod983_hsgd_to_roh083_light будет называться Остатки.

Заведите в _columns поле models_id...

dr.nomore
Крсавчег. Прямо всех урыл.
Только если перевести всю эту крсивую инсенуаацию, он будет звучать банально:

dr.nomore
я не понял чем вам мои запросы в information_schema не понравились, они работают и вытаскивают все что нужно о колонках, первичных ключах и внешних ключах одним запросом. Я не спорю, можно и по-другому их написать, но какая собственно разница, главное что мы хотим в результате получить.

Мускулем и постгресом я сам пользуюсь, поглядываю в сторону скулайта потому что реально бывают ситуации когда нет возможности поставить сервер базы, и тут скулайт спасет. Не вижу ничего маргинального в этих трех базах. + на практике приходится интегрировать сайты с разными микрософтовыми поделиями а также поделием 1с, поэтому в список добавляется мсскл, в его информэйшн_схему я даже не заглядывал, интуиция подсказывает что там тоже будут нюансы с отклонением от стандарта. Так что 4 субды имхо это тот минимум который покроет как раз не маргиналов.

Я люблю когда все лаконично, поэтому вариант с созданием доп. таблиц о схеме мне не нравится, т.к. алгоритм работы получается избыточный: нужно создать схему, создать описывающие схему доп. таблицы, научить скрипт доставать из этих доп. таблиц инфу чтобы прописать схему на пхп - это как-то слишком толсто получается.

Все субды умеют делать экспорт структуры в скл-файл, поэтому я решил что читать схему оттуда будет универсальнее и проще всего.

И давайте все же вернемся к классу. Как вы уже поняли, меня больше волнует вопрос удобного синтаксиса/интерфейса, если в этом плане есть предложения - очень жду

twin, у тебя зуб на доктора?)) По мне так нормальное повествование. Да и при таком уровне знаний, можно себе иногда позволить чуть больше

_____________
Стимулятор ~yoomoney - 41001303250491

Valick
Лучше ответьте на мой вопрос: вы стали бы использовать мои классы? если нет, то что отталкивает?

Aeq, честно скажу тему вообще не читал.
Со сколькими БД позволяет работать ваш класс?


_____________
Стимулятор ~yoomoney - 41001303250491

Если таки соберетесь почитать, то кроме первого поста, прочитайте еще этот: http://phpforum.su/index.php?showtopic=0&v...dpost&p=2675049 и следующий за ним

Да я уже прочел первый пост, и не нашел там реальных запросов, вы уж извините мою прямоту, но SELECT * FROM table, по мне так лучше в файле хранить данные.
Может я и не прав, но поверьте я даже PDO недолюбливаю. Хотя у них там свой драйвер работы с MySQL, а раньше использовался mysqli_ . И большинство программистов льстят себе расчитывая на то, что их приложение увидит БД отличную от MySQL

Для меня важна гибкость SQL запросов, а любая обертка враг той самой гибкости.
Может несколько сумбурно выражаю свою точку зрения, но это на все что способен в данный момент мой пьяный мозг)

_____________
Стимулятор ~yoomoney - 41001303250491

Valick
напишите мне пример реального запроса, чтоб я понял суть того что смог выдать ваш пьяный мозг ))) вообще, несомненно, сложные запросы проще писать на голом sql, я сам так делаю, и в этой теме уже не раз упоминал об этом.

Valick
кстати, конкретно эта обертка не враг голых sql. вы всегда можете написать

$result = $apdo->statement('любой запрос', [аргументы])->fetchAll();

а в качестве бонуса получаете ленивый коннект и кэшер.

Должен признать что зря наезжал. Нынче только сообразил что вы не можете запросто завести себе таблицу или пять, или десять и оперировать служебными данными в личных целях. Более того, наконец-то дошло откуда берутся текстовые конфиги в файлах и массивах. Я-то начал с того конца который был для меня привычен - с грядок и погряз не могя совместить нормальное отображение с ненормальным несмотря что по профессии дизайнер.

Десктопные приложения которые мне удалось написать все были построены на грядках, гридах, таблицах разного рода. Ну Абсцесс видели же? Первым делом я написал себе абсцесс для веба чтобы чинить БД подведомственных сайтов не касаясь их уродских админок и постепенно привык к мысли что нормальные админки все таковы. Что вы может завести таблицу и тут же ее заполнить, отредактировать, связать и посмотреть что вышло.

Вы не можете. Вам еще надо модель нарисовать или несколько, хтмл нарисовать, или несколько, все поля там расставить, стили повесить, обратную связь завести и только тогда, может быть, и в таком роде. Вполне понятно кому такой геморрой нужен.

Так что не слушайте меня.

CREATE TABLE `test_fruit` (
  `id` int(11) NOT NULL,
  `name` varchar(50) NOT NULL,
  `color` varchar(50) DEFAULT NULL,
  `tree_id` int(11) DEFAULT NULL,
  PRIMARY KEY (`id`),
  KEY `tree_id` (`tree_id`),
  CONSTRAINT `test_fruit_ibfk_1` FOREIGN KEY (`tree_id`) REFERENCES `test_tree` (`id`)
) ENGINE=InnoDB DEFAULT CHARSET=latin1