Проектирование крупных приложений БД

[superedward]

Сообщение от BARNEY

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

Я бы поостерегся давать такие громкие названия подобным вещам. Есть такое понятие срез набора данных. В зависимости от выполняемых задач каждый срез имеет свои параметры. Частный (простейший) случай - один срез ассоциируется с одним набором данных, но так бывает далеко не всегда. Причем пользователя зачастую интересует не только сам срез, но еще и различные промежуточные итоги - суммы и средние...
На самом деле всего лишь дело конкретной задачи - реализовывать для каждого среза отдельную форму/набор данных или нет.

Сообщение от BARNEY

сортировка делается по запросу (клику на заголовок, выбор в каком нибудь комбо боксе и т.д. )
Такую группировку как у вас я бы сделал слева от grida (не важно какого). пример аутглюк мелкомягких.
итоги в label в низу.

Замечательно, это я и хотел выяснить - всегда интересны подходы других программистов в решении сходных задач. Я тоже отказался от всяких DataSet и скармливаю данные компоненту самостоятельно.

Сообщение от BARNEY

Очень хочется увидеть как вы пользователю пол базы в интерфейс пихаете...

Боюсь, не смогу доставить вам такой радости - никогда ничем подобным не занимался и не собираюсь.

Сообщение от BARNEY

А как вы их там сгруппируете и размажете красиво на форме дело вкуса.

Программа - это лицо разработчика, и оно должно быть не только функциональным, но еще и удобным и красивым.
Это, если хотите, мое кредо.

Сообщение от BARNEY

Но заходя в программу пользователь точно знает что ему надо сделать..и меня лично всегда напрягает делать кучу манипуляций чтобы сделать конкретное действие.

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

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

[BARNEY]

Если говорим сейчас про отчеты и статистику и про срезы данных.
Я лично красиво выгружаю в Excel. Что даёт возможно всем участникам процесса смотреть свои данные из одного (не в буквальном смысле) отчета . Не возникает не каких споров и разночтений в разных отчетах.

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

[superedward]

Сообщение от BARNEY

Если говорим сейчас про отчеты и статистику и про срезы данных.
Я лично красиво выгружаю в Excel. Что даёт возможно всем участникам процесса смотреть свои данные

С этим согласен целиком и полностью. Можете поделиться исходником экспорта данных в xlsx? Как раз сейчас этим занимаюсь с целью поддержки последних версий Excel.

[MarazmDed]

Сообщение от Sciv

Положить пару компонент на форму и т.д. по тексту != создать БД. Расписывать на миллион страниц создание объемной БД - бессмысленно по двум причинам: 1) принципы создания реляционных БД не зависят от объема этих самых баз; 2) чем проще пример - тем проще в нем разобраться (читай - научиться).

Согласен, но, как всегда, есть одно "но": на маленьких примерах не очевидны проблемы больших программ. Свою проблему я описал в начале топика. Есть крохотная на самом деле БД из 20-30 таблиц. И есть желание использовать визуальные возможности Delphi. Меня ведь можно понять? Раз компоненты созданы, значит это кому-нибудь нужно. Но каждый раз делать одни и теже действия для одних и тех же датасетов, но в разных формах - не айс. И тут я понял, что я чего-то не понимаю. На этом форуме и хочу выяснить - чего именно.

[MarazmDed]

Сообщение от BARNEY

А чего order by в запросах уже запрещено использовать?

Можно. Но для этого нужно ручками писать запрос, вешать обработчики на стринггрид и т.д. Т.е. получается лишняя работа, которой хочется избежать. Вообще я создал этот топик, чтобы выяснить, существует ли способ создавать программы БД с минимальным кодированием. Я уже написал одно коммерческое приложение, полностью на стринггридах и Data-aware контролах. Результат мне не понравился. Не нравится как трудоемкость программирования интерфейса, так и скорость работы приложения.

Сообщение от BARNEY

Больше 6 записей у меня пользователю не покажет... оснавная таблица у меня прирастает в 1 000 000 записей в месяц. (ибо зачем ему там ковыряться)

Мысль следующая. Пользователю лимон записей не нужен по определению. Но сколько ему записей нужно? Ну можно организовать страничный просмотр. Но не все СУБД поддерживают выборку записей по номеру. И опять же, очень хотелось бы избежать программирования. Т.е. страничный просмотр - это то, что должен делать DataSet автоматически при указании FetchSize, а контрол должен делать Fetch - только тогда, когда это необходимо.

Сообщение от BARNEY

с чего хоть? 1 stringgrid универсально выводит любую информацию из любых запросов вообще без компонентов dataset

Неа. Он выводит только то, что ты туда выведешь. А я этого делать не хочу. Я хочу, чтобы оно само выводилось Ну по крайней мере подход "программируй все ручками" мне понятен. И я так делал. Не доволен результатом, теперь ищу способ, как использовать возможности RAD

Сообщение от BARNEY

А заранее перед нажатием клавиши вы в запросе не перечисляете поля которые нужно вывести..или тупо если таблица 100 на 100 всё выводите? включая не нужные пользователю технические поля.

Нет. Я пользую компонент Table, а не Query. Дык в том и вопрос. Там мало просто перечислить поля, там надо еще каждому полю русский заголовок написать. А это утомляет.

Сообщение от BARNEY

Всегда юзал отдельные формы для заполнения справочников, прямой доступ к базе давать это от Лукавого

Почему прямой? Через DBGrid

[MarazmDed]

Сообщение от superedward

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

Лукап я привел в качестве примера, конечно же. Просто каждый экземпляр датасета отнимает много времени, что не приемлемо. Да и вообще дубляж - плохой тон. Потому и пытаюсь определить способ: 1) как не изобретать велосипед, 2) остаться в рамках концепции RAD.
Идеальный вариант для меня - узнать какую-нибудь фишку IDE, которая решит мои проблемы Ну вдруг это редактор диаграмм из Delphi 6?

Сообщение от superedward

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

Вот с этого момента можно поподробнее и по два раза?
Что именно за подход? Все же ручное создание Dataset'ов из кода?

Сообщение от superedward

Кроме того, программная часть тоже самодостаточна, т.е. позволяет создавать новые базы данных без дополнительных приложений.

Т.е. некая реализация шаблона MVC? Тогда можно об этом подробнее?

Сообщение от superedward

А как это выглядит визуально StringGrid в качестве отображения данных? Интересует, реализованы сортировка, группировка, итоги?

Пардон, а как его использовать? Создать новый компонент, наследник от StringGrid, получив тем самым свою версию DBGrid?
Этот вариант - велосипед. В инете можно найти готовые варианты гридов, не такие уродские как DBGrid.
Каждый раз тупо навешивать обработчики и дублировать код? Вообще не вариант.

Сообщение от superedward

Аватар, в принципе, прав. Зачем пользователю миллион записей, если он их даже за целый рабочий день не сможет просмотреть?

А сколько пользователю нужно записей? Ну да, миллион он не просмотрит, но надо дать ему возможность. Пусть сам решает, когда ему надоест. Если речь про организацию страничного вывода - это другой вопрос. Но опять же, хотелось бы искренне верить, что это умеет делать DataSet + DBGrid. Да и миллион взят из головы. Суть в том, чтобы не хранить весь датасет в гриде - слишком много памяти отъест. Если же делать страничный вывод в стринггрид РУЧКАМИ - то это адЪ. А я хочу ада избежать )

[Yurk@]

Пользователю лимон записей не нужен по определению. Но сколько ему записей нужно?

такое понтие как "фильтр" который выскакивает сразу перед открытием таблицы разве не знаком? перед тем как открыть набор данных - указываем условия поиска и получаем результат из 5-10 (или чуточку больше) значений, но уж никак не 100 тыс. или 1 млн.

Почему прямой? Через DBGrid

это и есть прямой
ну а вообще неозможно сделать нормальное приложение не приложив к нему достаточного кол-ва кода - в этом то и вся работа.

[MarazmDed]

Сообщение от BARNEY

сортировка делается по запросу (клику на заголовок, выбор в каком нибудь комбо боксе и т.д. )

Т.е. для каждого грида вы дублируете код?

Сообщение от BARNEY

По этому голый sql на стороне сервера + передача готовых данных пользователю.

А как реализовать страничную выборку из запроса средствами SQL?

[Yurk@]

А как реализовать страничную выборку из запроса средствами SQL?

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

[MarazmDed]

Сообщение от Yurk@

такое понтие как "фильтр" который выскакивает сразу перед открытием таблицы разве не знаком? перед тем как открыть набор данных - указываем условия поиска и получаем результат из 5-10 (или чуточку больше) значений, но уж никак не 100 тыс. или 1 млн.

Ну а теперь представим, что в результате фильтрации пользователь выбрал лимон записей. И что тогда? Не показывать их ему? Сказать, что ему столько не надо? Вопрос опять же не в том. Вопрос в том, что данные в гриде сидят в памяти. Fetch из DataSet отдает данные порциями. Т.е. мы при DBGriid + DataSet и грамотной настройке не отожрем пару гигабайт памяти. А вот при query + StringGrid - запросто. Вывод же данных на нашей совести.

Сообщение от Yurk@

ну а вообще неозможно сделать нормальное приложение не приложив к нему достаточного кол-ва кода - в этом то и вся работа.

Дык я для того и создал топик, чтобы 1) узнать то, чего не знаю я - как другие делают 2) определить разумный баланс rapid-development'а и ручного кодирования. Беда в том, что даже если по полной использовать визуальный подход, все равно останется прорва мест, которые нужно программировать - бизнес-логика. Не хочется делать рутину. Хочется либо юзать библиотеки, либо возложить работу на могучие плечи Delphi