Большая часть большей части интерфейсов к БД не содержит ничего необычного; так, формы как формы. Редко-редко когда понадобится какой-нибудь график. Было бы здорово иметь стандарт DBML, который, будучи приложен к любой базе, описывал бы КАК она должна быть представлена пользователю. Вводил бы хитрые ограничения на значения, не реализуемые в SQL, содержал описания полей, абстрагировал бы BLOB'ы, пряча их за типизированными файлами. После чего произвольным клиентом DBML (как веб-, так и толстым) можно было бы обрабатывать любую базу. Только добавь воды. Метаинформацию в формате DBML.
Ведь сдох бы тогда шаропоинт, а, господа? С одной стороны, профессионалы были бы недовольны. Сейчас они за каждое конкретное исполнение бабки берут. С другой, доволен был бы юзер. Удалось бы, как я это называю, "взорвать профика"? Кто-нибудь расскажет про известные ему попытки?
Здравствуйте, SV., Вы писали:
SV.>Большая часть большей части интерфейсов к БД не содержит ничего необычного; так, формы как формы. Редко-редко когда понадобится какой-нибудь график. Было бы здорово иметь стандарт DBML, который, будучи приложен к любой базе, описывал бы КАК она должна быть представлена пользователю. Вводил бы хитрые ограничения на значения, не реализуемые в SQL, содержал описания полей, абстрагировал бы BLOB'ы, пряча их за типизированными файлами. После чего произвольным клиентом DBML (как веб-, так и толстым) можно было бы обрабатывать любую базу. Только добавь воды. Метаинформацию в формате DBML.
SV.>Ведь сдох бы тогда шаропоинт, а, господа? С одной стороны, профессионалы были бы недовольны. Сейчас они за каждое конкретное исполнение бабки берут. С другой, доволен был бы юзер. Удалось бы, как я это называю, "взорвать профика"? Кто-нибудь расскажет про известные ему попытки?
У меня примерно такое релизовано на объектно-реляционной модели в Postgresql в виде объекта "Форма". Проблема в том, что руки до генератора форм пока не дошли, приходится шаблонную формочку делать руками, потом в БД, а потом для каждой задачи размножать.
Здравствуйте, cvetkov, Вы писали:
C>есть ECO например
Это немного не то. Я имел в виду не фреймворк, а стандарт на метаинформацию и полностью готовых клиент(ов), которые по этой стандартизированной мете генерируют формы. Разработчик БД теряет возможность втюхать одноразового говноклиента, и, конечно, не будет в восторге, но юзера же можно подмаслить хорошим интерфейсом. Кнопочками там стеклянными и всем в таком духе. Чтоб он требовал от базоданщика совместимости.
Здравствуйте, SV., Вы писали:
SV.>Большая часть большей части интерфейсов к БД не содержит ничего необычного; так, формы как формы. Редко-редко когда понадобится какой-нибудь график. Было бы здорово иметь стандарт DBML, который, будучи приложен к любой базе, описывал бы КАК она должна быть представлена пользователю. Вводил бы хитрые ограничения на значения, не реализуемые в SQL, содержал описания полей, абстрагировал бы BLOB'ы, пряча их за типизированными файлами. После чего произвольным клиентом DBML (как веб-, так и толстым) можно было бы обрабатывать любую базу. Только добавь воды. Метаинформацию в формате DBML.
XSD\InfoPath
SV.>Ведь сдох бы тогда шаропоинт, а, господа?
Никуда бы он не делся.
SV.>Кто-нибудь расскажет про известные ему попытки?
InfoPath.
Без кода только простые формы получаться. А если нужен код, то как его цеплять к такому метаописанию?
Здравствуйте, SV., Вы писали:
SV.>Это немного не то. Я имел в виду не фреймворк, а стандарт на метаинформацию и полностью готовых клиент(ов), которые по этой стандартизированной мете генерируют формы. Разработчик БД теряет возможность втюхать одноразового говноклиента, и, конечно, не будет в восторге, но юзера же можно подмаслить хорошим интерфейсом. Кнопочками там стеклянными и всем в таком духе. Чтоб он требовал от базоданщика совместимости.
Так там и есть стандарт на метоинформацию, который называется MOF (если мне память не изменяет).
из этой метаинформации и база генерируется и клиент.
Вообще если интересна эта тема то можно прочитать про MDA.
Есть еще один тул AndroMDA который похожими вещами занимается. но у него какойто свой формат метаинформации.
Здравствуйте, cvetkov, Вы писали:
C>Так там и есть стандарт на метоинформацию, который называется MOF (если мне память не изменяет). C>из этой метаинформации и база генерируется и клиент.
Я ж говорю, не то. Клиент генерируется, а не поставляется как законченный продукт.
Здравствуйте, SV., Вы писали:
SV.>Здравствуйте, gandjustas, Вы писали:
G>>Без кода только простые формы получаться. А если нужен код, то как его цеплять к такому метаописанию?
SV.>В 90% случаев как раз обходятся без кода.
Не спорю, но те 10% где код нужен, стоят 95% всех затрат.
Дьявол как всегда в деталях, нужен хороший способ писать код к метаописанию, иначе смысла в метаописани немного.
Здравствуйте, SV., Вы писали:
SV.>Я ж говорю, не то. Клиент генерируется, а не поставляется как законченный продукт.
можно и не генерировать. оно (ECO) умеет (умело раньше по крайней мере) работать в режиме интерпретации.
Здравствуйте, gandjustas, Вы писали:
G>Здравствуйте, SV., Вы писали:
SV.>>Здравствуйте, gandjustas, Вы писали:
G>>>Без кода только простые формы получаться. А если нужен код, то как его цеплять к такому метаописанию?
SV.>>В 90% случаев как раз обходятся без кода.
G>Не спорю, но те 10% где код нужен, стоят 95% всех затрат. G>Дьявол как всегда в деталях, нужен хороший способ писать код к метаописанию, иначе смысла в метаописани немного.
Кстати еще один красивый способ: делать метаописание на самом языке программирования.
Здравствуйте, gandjustas, Вы писали:
G>>>>Без кода только простые формы получаться. А если нужен код, то как его цеплять к такому метаописанию? SV.>>>В 90% случаев как раз обходятся без кода.
G>>Не спорю, но те 10% где код нужен, стоят 95% всех затрат. G>>Дьявол как всегда в деталях, нужен хороший способ писать код к метаописанию, иначе смысла в метаописани немного.
G>Кстати еще один красивый способ: делать метаописание на самом языке программирования.
Это уже очень далеко от того, что вижу я. Попробую описать подробнее.
Use case 1. Вам надо создать систему учета валенков на складе.
Имеющиеся варианты:
Взять готовую систему по учету товара, забить в справочник "Валенки". Недостатки — подобные системы обычно платные (опенсорсно писать такие вещи неинтересно), не поддаются контролю (всегда пытаются сделать платформу, в частности, свой бэкап и далее по всем кочкам), вы не можете интегрироваться с существующими CRM на более позднем этапе, если интеграция не предусмотрена авторами. Вариант "Расшарить .xls в сетевой папке" из той же оперы, только заведомо ненадежный.
Написать самому с нуля и базу, и клиента, благо писать обычно недолго. Недостатки — клиента сопровождать запаришься, если доработка не за отдельные деньги. Юзерам же всегда в самом конце хочется целого набора фич, скажем проверки правописания при наборе марки валенок (хорошо, если хотя бы веб-клиент их устраивает — можно выкрутиться, поставив плагин в браузер).
В нашем же случае, вы создаете обычную БД (в любой СУБД), в ней — таблицу feltboots с колонками brand nvarchar (255) и number int, а кроме того — внимание! — мету в формате DBML. Формат описывает таблицы в этой же БД (а никакой не язык программирования). Готовый клиент (на выбор из существующих) обращается к БД, считывает мету, понимает, что вам надо работать с единственной таблицей, что у таблицы алиас — "Валенки", что в ней хранятся записи о двух полях — "Марка" и "Количество". Плохой клиент умеет показывать кластеры таблиц, для каждой таблицы — отображать все записи, удалять произвольные, вносить новые, редактировать имеющиеся, при этом не дает вам редактировать вычисляемые поля. Хороший клиент кроме перечисленного умеет накладывать фильтры, производить разбивку, показывать суммы, отклонения, дисперсию (все, разумеется, через СУБД), поддерживает экранную геометрию объектов, цвета и шрифты, а также умеет генерировать новые таблицы и новую мету (таким образом, создать таблицу feltboots можно через него же).
Use case 2. Вам надо прикрутить ленту новостей к сайту.
Имеющиеся варианты:
Взять CMS типа Joomla. Недостатки — у каждой CMS свои . Общий же недостаток — зависимость от выбранного пути.
Редактировать HTML. Недостатки — прощай разбивка и архив, а также подсчет количества и подстановка авторов.
Хранить новости в БД, подставлять в страницу, используя простые скриптики на, скажем, PHP. Для редактирования прибегать к myClient или SQL SMS. Недостатки — клиенты БД очень суровые и простому юзеру их давать нельзя. Даже форматирование текста придется задавать руками (о боже).
Что делаем мы. Создаем не только таблицу новостей, но и мету. Подставляются они в страницу "простыми скриптиками на, скажем, PHP", а вот редактируются тем же самым клиентом. (Лично я в таких случаях всегда ставил в задницу сайту phpBB, а потом дергал его базу, но это ощущалось противоестественно).
Кстати, о phpBB. Use case 3. Вам надо с телефона общаться на форуме (например, vB).
Имеющиеся варианты:
Пользоваться браузером, предусмотренным телефонистами (Pocket IE, Opera Mini или что там еще). Который порвет пупок себе и глаз вам в попытках отобразить мегадизайн авторов vB, эгоистично не подумавших о вашем телефоне. Графика не пролезает через жопорез, а пролезши рвет экран в клочья, и так далее.
Написать аскетичный фронтенд к БД форума.
Пишем мету к имеющейся БД, в дальнейшем пользуемся мобильным клиентом DBML.
Несколько слов о неочевидных мелочах.
1. Многие, наверное, не захотят выставлять БД наружу (небезопасно, порты заблокированы и пр.). В этом случае, можно было бы стандартизировать необязательную таблицу пользователей, и применять онлайновый клиент DBML, в конфиг которого положены cridentials одного-единственного пользователя СУБД. Хотя лично я предпочел бы не множить сущности. Либо разбить толстого клиента на серверную и чисто клиентскую части, в конфиг серверной, опять же, прописать единственного БД-юзера.
2. Код, который иногда нужен. Ну, коду место в триггерах.
Мотив, который за этим стоит — KISS. Это антипрофессионально, конечно же. (Жду не дождусь, когда профи осознают, наконец, о чем идет речь и завалят тремя слоями кала). Но, как я говорил выше, если сделать клиента вкусным для пользователей, насовав им не только спелл-чекеров, но и прозрачных кнопок, есть шанс "взорвать профи" (что MS делало всю жизнь, и за что их всегда так ненавидели). Если кто-то узнал знакомые очертания, дайте названия неудавшихся попыток, хочу посмотреть, кто на чем обломался.
. Общий же недостаток — зависимость от выбранного пути.