-
> У ANTPro © (05.12.08 18:14) [16] Пока многое еще неизвестно,
> может и финансирование будет
> А вы ему значит помочь хотите с финансированием? :)
-
Anatoly Podgoretsky © (05.12.08 20:42) [40]
Как оказалось не хотят. Только обсудить и тоже на халяву :)
-
> blackman (05.12.2008 20:46:41) [41]
Надо не говорить, а пилить.
-
Anatoly Podgoretsky © (05.12.08 22:21) [42]
Когда есть что и это что золото
А пока остается только говорить... :)
-
Microsoft Query
Это ексель->Data->Import External data
-
Тест для простого пользователя - конструирование сводной таблице в ёкселе. 90% не могут. Остальные 10% можно допускать к конструктору акцесса.
-
-
> [19] clickmaker © (05.12.08 18:36)
Это интересный вариант, хотя если присмотреться, то везде похоже сделано.
Возможно в виде мастера такая реализация будет проще для пользователя.
> [46] Омлет (06.12.08 23:24)
Спасибо посмотрю.
> [44] Карелин Артем © (06.12.08 11:18)
Тут слишком много кнопочек :о)
-
Я как-то на старой рботе видал такую штуку - Bussiness Objects называлась. В деталях не помню, но вроде как, к большинсту СУБД подрубалась и могла всякие отчеты на основании имеющихся данных строить. Правда, дорогучая, вроде, была. Да и обучения некоторого требовала, но менеджеры вроде как справлялись.
-
> Ega23 © (05.12.08 16:54) [1]
>
> гм...
> ИМХО, не бывает "простого пользователя", который может составлять
> SQL-запрос.
>
> А так - Select * from table. :)
Бывает. Hibernate в Java, там можно тупо прописать мапинги таблиц и связей в xml и движок сам построит запросы, причём оптимизирует запрос под выбранный сервер. Не визуально, но проще чем писать самому.
-
А вообще ищи про ORM http://ru.wikipedia.org/wiki/ORMГде все данные можно представить в виде объектов, но для Delphi ничего толкового нет(сам писал минидвижок), только для Delphi.Net
-
> kaif © (05.12.08 19:06) [25]
> Мне кажется, что юзер любит сразу видеть результат.
> Если сделать так, что по мере конструирования запроса, система
> будет выдавать какие-то частичные результаты: сама ограничивая
> наборы по объему, вводя дополнительные условия за кадром
> и следя за тем чтобы юзер не устроил декартово произведение
> сдуру на большом наборе, предвосхищала бы примерно время,
> которое он получит в "рабочем" варианте, то что-то подобное
> могло бы оказаться полезным. И не только юзерам, но и нашему
> брату SQL-щику.
1. Очень сложно получится перехватывать все дури юзера (предотвращение кортезианов (хотя иногда кортезиан - как раз то, что нужно), вытаскивание всей таблицы (на пару миллиардов записей)). В общем случае, запросы, писанные как попало, будут работать на достаточно небольшой базе и при условии мощного сервера. Хотя кортезианами можно и малым обьемом сервер уложить.
2. Все равно получится сложно и юзеры будут звать программиста. Примеров куча : тот же SQL, 1С . . . (изначально задумывалось, что программист будет не нужен).
Так что :
> blackman © (05.12.08 19:54) [34]
+1.
-
> kaif © (05.12.08 19:06) [25]
> Мне кажется, что юзер любит сразу видеть результат.
> Если сделать так, что по мере конструирования запроса, система
> будет выдавать какие-то частичные результаты: сама ограничивая
> наборы по объему, вводя дополнительные условия за кадром
> и следя за тем чтобы юзер не устроил декартово произведение
> сдуру на большом наборе, предвосхищала бы примерно время,
> которое он получит в "рабочем" варианте, то что-то подобное
> могло бы оказаться полезным. И не только юзерам, но и нашему
> брату SQL-щику.
1. Очень сложно получится перехватывать все дури юзера (предотвращение кортезианов (хотя иногда кортезиан - как раз то, что нужно), вытаскивание всей таблицы (на пару миллиардов записей)). В общем случае, запросы, писанные как попало, будут работать на достаточно небольшой базе и при условии мощного сервера. Хотя кортезианами можно и малым обьемом сервер уложить.
2. Все равно получится сложно и юзеры будут звать программиста. Примеров куча : тот же SQL, 1С . . . (изначально задумывалось, что программист будет не нужен).
Так что :
> blackman © (05.12.08 19:54) [34]
+1.
-
> Я как-то на старой рботе видал такую штуку - Bussiness Objects
> называлась. В деталях не помню, но вроде как, к большинсту
> СУБД подрубалась и могла всякие отчеты на основании имеющихся
> данных строить. Правда, дорогучая, вроде, была. Да и обучения
> некоторого требовала, но менеджеры вроде как справлялись.
>
У нас стоит. И к ней 2 отдела программистов :)
-
> asail (07.12.08 23:10) [48]
+1
-
> ANB (08.12.08 10:43) [51]
Ну так пропишите мапинги таблиц и будет вам счастье. Запросы будет стоить система, а кривой мапинг визуально обнаружить проще чем муторный запрос.
-
> ANB (08.12.2008 10:43:51) [51]
> тот же SQL, 1С . . . (изначально задумывалось, что программист будет не нужен).
И здесь тоже, видимо тоже лавры IBM не дают.
-
> Ну так пропишите мапинги таблиц и будет вам счастье. Запросы
> будет стоить система, а кривой мапинг визуально обнаружить
> проще чем муторный запрос.
И запросы будут строить наши юзеры ?
Я лучше сразу пойду застрелюсь вместе с DBA.
-
> ANB (08.12.2008 13:00:57) [57]
Для проверки, первым пусти DBA
-
> ANB (08.12.08 13:00) [57]
А щапрос будет в такой вот форме
<hibernate-mapping>
<class name="logic.Bus" table="busses">
<id column="bus_id" name="id" type="java.lang.Long">
<generator class="increment"/>
</id>
<property column="number" name="number" type="java.lang.String"/>
<set name="drivers" table="busDriver" lazy="false">
<key column="bus_id"/>
<many-to-many column="driver_id" class="logic.Driver"/>
</set>
</class>
</hibernate-mapping>
http://habrahabr.ru/blogs/java/29694/
|
Есть новые 
Нет новых [134446 +39][b:0][p:0.001]