wxWidgets Discussion Forum

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

Я на сколько помню, в ultimate++ тоже нету нормального датагрида, так что в плане GUI тут можно выбрать любой вариант. Зато в wxWidgets есть DatabaseLayer и wxActiveRecordGenerator.

Там есть ArrayCtrl, который вроде бы тоже что то умеет делать. Есть некие классы для работы с БД - SqlArray, и обертки над PostgreSQL, MySQL, OLEDB.
Вот чего точно там не увидел это PropertyGrid.
Мне что нравится, что там в U++ есть оптимизированные контейнеры с механизмом Copy-On-Write.

Заканчиваем проект на wxWidgets и активной работой с базами данных.
Идея простая и хорошо себя зарекомендовавшая уже лет 10. Не делаем никакой привязки "GUI-база данных". Из базы прочитали в вектор затолкали, на гриде показали, поредактировали, ... В базу данных записали. Тот же вектор если надо с "листбоксе", "чойсе" показали.
Были правда небольшие проблемы с DatabaseLayer-ом, и есть проблемы с построителем отчетов.
Для отчетов пока обошлись wxPdfDoc. Делаем в для него шаблон в котором наши специальные теги, в них данные и подставляем.
Если тебя GPL не ограничивает и несть время прикрутить wxDatabaseLayer к ISQLReport, то можно пробовать его юзать.

Вот так оно выглядит

vtararin wrote:Заканчиваем проект на wxWidgets и активной работой с базами данных.
...

Большое спасибо за описание вашего опыта. У меня тогда к Вам еще пару вопросов, если можно.
Вектор стандартный std::vector или wx вариант?
Есть ли необходимость показывать большие объемы, тогда вроде бы хранить в массиве становится не выгодно?

Есть ли необходимость показывать большие объемы, тогда вроде бы хранить в массиве становится не выгодно?

Это лучше чем для виртуального ListView например подгружать постоянно из БД значения. Особенно если сервер не embedded (да хотя и у embedded тоже быстродействие не ахти).
Delphi например весь рекордсет в памяти хранит.

Узаем std::vector.
Интерфейс построен так, что пользователю нет необходимости смотреть огромные объемы данных.

Мы исторически (с 1996 года) выработали стратегию, показывать пользователю не более 2000 записей при запросе. Если зпрос возвращает больше, то уведомляем пользователя и пусть работает с фильтром. Ни разу ни одного нарекания от пользователя не было.

Так что вопрос со скролированием больших объемов и не стоял, а 2000 объектов в ОЗУ это совсем не много.

При работе с базами скролирование через базу данных - это плохая затея. Есть СУБД которые не поддерживают скролирующиеся курсоры совсем (Oracle 7 и 8, PostgreSQL 7,8.0 например), есть СУБД которые сбрасывают курсоры при окончании транзакций (Interbase например), есть СУБД которые при чтении (скролировании) выставляют блокировки по чтению (MSSQLServer, уровень изоляции не грязное чтение). И в любом случае - это очень сильно повышает нагрузку на сервер.

У меня вот еще вопросы появились
Если использовать wxWidgets, то возникает желание использовать Boost, там много разных вкусностей. Это нормальное желание?

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

Если использовать wxWidgets, то возникает желание использовать Boost, там много разных вкусностей. Это нормальное желание?

Ну, скорее нет чем да. В wxWidgets есть нормальные контейнеры и вобще возможностей вполне достаточно для нормальной работы.
Там вон про синхронизацию, дык тоже есть wxCriticalSection, wxMutex, ну в общем все как у людей. Хотя да, никто не запрещает юзать boost но особых выгод в этом не вижу. Опять же, на вкус и цвет фломастеры разные.

DmP wrote:как лучше делать?

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

Кстати, реализовать стратегию на основе версий строк с использованием wxDatabaseLayer не удасться, т.к. он не предоставляет кол-во измененных записей на операциях update и delete, а без этого не работает. Хотел было эту фичу прикрутить, но времени совсем нету.

Хотел было эту фичу прикрутить, но времени совсем нету.

+1. Так нехватает этой штуки. В MySQL кое-как можно еще вывернуться родными вызовами, в остальных все некогда разобраться, хотя там скорее всего не так много работы. Может в bounties вывести этот таск и студентам показать?

Всем большое спасибо за ответы! Узнал много важного, теперь нужно все обдумать и поискать книги.

T-Rex wrote:Может в bounties вывести этот таск и студентам показать?

По большому счету wxDatabaseLayer нужно перелопатить по образу и подобию
zeoslib. Сейчас изать его довольно тяжело, сыроват он и концептуально и в реализации.

Скачал zeoslib, гляну на досуге.

А по поводу Databaselayer, ну, jb_coder вроде автор, как-то он так консервативно к багрепортам относится. я как-то постил пару раз, толку ноль. надо самому фиксить.
С другой же стороны я вижу выход не в переделывании DatabaseLayer а в апгрейде wxARG до вменяемого вида, чтобы оно хотя бы со старту компилилось и работало корректно. Мне например wxARG очень по душе.