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

  is(!is_array($value)) $value = (array) $value;

ну да, не одну, но только по id, а если мне надо удалить все фрукты с истекшим сроком годности, в своем я напишу ->where('годен_до < now()')->delete() , а в вашем варианте как? или удалить все с красным цветом у меня будет ->key('red', 'color')->delete() , а у вас?

главное чтоб полезные выводы из такого обсуждения вывелись. я например для себя придумал чем заняться в предстоящие выходные, запилить еще один уроверь абстракции над моим APDO, который будет читать схему, для начала под mysql, дальше посмотрим.

в своем я напишу ->where('годен_до < now()')->delete() 

в моей модели будет метод "удалить просроченные фрукты" например, который будет выполнять эту операцию например. Оператор будет тыркать кнопочку когда ему надо, которая будет вызывать этот метод например ))

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

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

Это продолжение метода отстранения от реляций. Чтобы ни одна извилина не дай бог не загнулась.

Так вот SQL, если вы вообще его видите за классами генерации SQL, изобретен для того чтобы _человек_ мог общаться с реляционной БД на человеческом языке.

А наш язык - язык программистов, бесчеловечный. Оператор может научиться строить запросы почитав мануал и напишет без нашей помощи

delete from фрукты where date between now and чо-то там еще, я не пользовался ни разу потому что сам себе делаю эти фильтры и поиск.

На языке классов никто кроме вас ничего не напишет. Вот куда скатился SQL.

---

Вы же видели консоль СУБД. Майскуля. Все в точности как в каком-нибудь cmd.exe только работа с бд, а не с файловой системой которая тоже БД.

Оно и хтмл умеет вводить и xml и, наверно, напечатать можно, не говоря о том чтобы в файл записать результат любого запроса. Там все есть, все уже давно оборудовано, а мы с вами обсуждаем работу с API и ПО на базе этого API.

Точная аналогия того же cmd.exe и скажем Проводника Виндоуз, или там FAR'а. Вот эти проводники мы и пишем. В графическом слегка виде, а на самом деле такие же убогие текстовые, потому что хтмл это текст.

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

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

Я и не прошу юзверей писать на языке моего класса, как такое вообще могло в голову прийти??

Опять насмешили. Эта кнопочка называется CREATE VIEW AS SELECT и бла-бла-бла...

Короче нарисовал удачный SQL и в мемориз. Припоминаю в РМА есть такая фича. Я не пользовался. Но для себя писал, на десктопе. Написал и все равно не пользовался.

Приложение к БД полностью оправдано когда оно связывает БД с небедешными сущностями. Скажем коннект, файлы, потоки, и тп.

Кстати, у вас же включена хронология запросов в браузере - хистори называется. Позволяет вводить адреса с подскзкой. У меня отключена. Чтобы зайти на этот форум я набираю phpforum.ru и жму ентер.

На самом деле все очень легко когда натренировался. Мы сколько тут уже кБ написали? А есть люди которые не писать не читать не умеют. Для них снимают видео. Видео-инструкция, видео-урок, видео-фак, видео-ответ и тп.

Вот так.

Тогда зачем вам БД. Пишите данные в файл. Вот так.

речь вроде шла об операции удаления просроченных фруктов, при чем тут вьюхи?

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