Значит, ситуация такова.
Предприятие, в нем есть очень много отчетных форм (обычно excel), необходимо все отчетный формы "оцифровать". То есть, необходимо данные хранить в БД, юзерам давать возможность вводить те данные, которые касаются только их, руководителям видеть у себя полную информацию с возможностью анализа (диаграммы, схемы, сегодня <--> вчера <--> прошлый год).
Само собой, этих форм немеренно, и их количество не собирается уменьшатся, поэтому кодировать каждую нет смысла. Необходимо создать какой то глобальный модуль.
Может ли кто чего посоветовать? Аналоги, статьи...
Разрабатываться будет на Delphi, БД скорее всего mysql, хотя это не принцпиально, так как я сам и постановщик и руководитель проекта.
Здравствуйте, ironwit, Вы писали:
I>Значит, ситуация такова. I> Предприятие, в нем есть очень много отчетных форм (обычно excel), необходимо все отчетный формы "оцифровать". То есть, необходимо данные хранить в БД, юзерам давать возможность вводить те данные, которые касаются только их, руководителям видеть у себя полную информацию с возможностью анализа (диаграммы, схемы, сегодня <--> вчера <--> прошлый год). I> Само собой, этих форм немеренно, и их количество не собирается уменьшатся, поэтому кодировать каждую нет смысла. Необходимо создать какой то глобальный модуль.
OLAP?
I> Разрабатываться будет на Delphi, БД скорее всего mysql, хотя это не принцпиально, так как я сам и постановщик и руководитель проекта.
Есть на самом деле. Во-первых глюк с потреблением памяти. Как ни крути, но 300 метров под маленькую БД, это слишком дофига. Во-вторых, медленно. По сравнению с MS SQL очень медленно. После перевода базы на MS SQL скорость обработки данных возросла примерно на порядок.
Вот так вот.
GuinPin -> "Re: необходима отчетная система" :
I>> Разрабатываться будет на Delphi, БД скорее всего mysql, хотя это не I>> принцпиально, так как я сам и постановщик и руководитель проекта.
G> Есть на самом деле. Во-первых глюк с потреблением памяти. Как ни G> крути, но 300 метров под маленькую БД, это слишком дофига. Во-вторых,
Ну да, рассказывай сказки. Во первых, этот баг давно пофиксили, а
во-вторых — все таки читать доки — оно того, полезно, развивает. Там описаны
всякие интересные ключики, хотя конечно их придется править в конфиге
ручками, после Enterprise Manager'a оно конечно ломать будет.
G> медленно. По сравнению с MS SQL очень медленно. После перевода базы G> на MS SQL скорость обработки данных возросла примерно на порядок. G> Вот так вот.
Ну давай примеры запроса. А то какие голословные утверждения.
ЗЫ Хотя от VARCHAR первичных ключей уже нично не спасет
Yury Kopyl aka hrg | http://id.totem.ru | "Сегодня с нами ты не пьешь, а
завтра Родине изменишь!"
hrg>Ну да, рассказывай сказки. Во первых, этот баг давно пофиксили, а
Да, очень давно? Я последний раз скачивал где-то с месяц назад.
hrg>во-вторых — все таки читать доки — оно того, полезно, развивает. Там описаны hrg>всякие интересные ключики, хотя конечно их придется править в конфиге hrg>ручками, после Enterprise Manager'a оно конечно ломать будет.
Не думаю, что будет Ломало дет 5 назад, когда линукс осваивал
А доки, да... Читать полезно. Согласен
G>> медленно. По сравнению с MS SQL очень медленно. После перевода базы G>> на MS SQL скорость обработки данных возросла примерно на порядок. G>> Вот так вот.
hrg>Ну давай примеры запроса. А то какие голословные утверждения.
hrg>ЗЫ Хотя от VARCHAR первичных ключей уже нично не спасет
Пример запроса: SELECT id, name, descr FROM nomen
первичный ключик id(int)
name (varchar 150)
descr (varchar 200)
На самом деле, я не совсем корректно выразился. Сравнивалось не выполнение запросов в чистом виде, а время загрузки данных в мою программу.
Приложение написано на VB .NET и единственное, что было изменено, это провайдер — было ODBC MySQL, стало SQLClient.
На старте загружается весь справочник (более 53 килозаписей). Когда перекинул провайдера на SQLClient, то сначала решил, что по тихой грусти LIMIT в запрос воткнул. Ан нет...
G hrg>> Ну давай примеры запроса. А то какие голословные утверждения.
hrg>> ЗЫ Хотя от VARCHAR первичных ключей уже нично не спасет
G> Пример запроса: SELECT id, name, descr FROM nomen первичный ключик G> id(int) G> name (varchar 150) G> descr (varchar 200)
G> На самом деле, я не совсем корректно выразился. Сравнивалось не G> выполнение запросов в чистом виде, а время загрузки данных в мою G> программу. G> Приложение написано на VB .NET и единственное, что было изменено, это G> провайдер — было ODBC MySQL, стало SQLClient. G> На старте загружается весь справочник (более 53 килозаписей). Когда G> перекинул провайдера на SQLClient, то сначала решил, что по тихой G> грусти LIMIT в запрос воткнул. Ан нет...
Ну тут тормоза не в БД, а ODBC реквестере. Я юзаю прямые компоненты доступа.
Летает
А почему не подходит генератор отчетов типа Crystal Reports для отчетных форм?
I>Значит, ситуация такова. I> Предприятие, в нем есть очень много отчетных форм (обычно excel), необходимо все отчетный формы "оцифровать". То есть, необходимо данные хранить в БД, юзерам давать возможность вводить те данные, которые касаются только их, руководителям видеть у себя полную информацию с возможностью анализа (диаграммы, схемы, сегодня <--> вчера <--> прошлый год). I> Само собой, этих форм немеренно, и их количество не собирается уменьшатся, поэтому кодировать каждую нет смысла. Необходимо создать какой то глобальный модуль. I> Может ли кто чего посоветовать? Аналоги, статьи... I> Разрабатываться будет на Delphi, БД скорее всего mysql, хотя это не принцпиально, так как я сам и постановщик и руководитель проекта.
I> Спасибо.
Здравствуйте, <Аноним>, Вы писали:
А>Здравствуйте, ironwit, Вы писали:
А>А почему не подходит генератор отчетов типа Crystal Reports для отчетных форм?
Здравствуйте, ironwit, Вы писали:
I>Здравствуйте, <Аноним>, Вы писали:
А>>Здравствуйте, ironwit, Вы писали:
А>>А почему не подходит генератор отчетов типа Crystal Reports для отчетных форм?
I>а через него можно данные вводить в БД?
генераторы отчетов предназначенны в первую очередь для вывода информации на экран(принтер), некоторые поддерживают експорт полученных данных в различные форматы (txt, exel, word ...)
Здравствуйте, FantomGood, Вы писали:
FG>Здравствуйте, ironwit, Вы писали:
I>>Здравствуйте, <Аноним>, Вы писали:
А>>>Здравствуйте, ironwit, Вы писали:
А>>>А почему не подходит генератор отчетов типа Crystal Reports для отчетных форм?
I>>а через него можно данные вводить в БД? FG>генераторы отчетов предназначенны в первую очередь для вывода информации на экран(принтер), некоторые поддерживают експорт полученных данных в различные форматы (txt, exel, word ...)
это я примерно знаю. Но в первичном сообщение было также указано что необходимо и вводить данные в БД.
I>> Разрабатываться будет на Delphi, БД скорее всего mysql, хотя это не принцпиально, так как я сам и постановщик и руководитель проекта.
GP>Есть на самом деле. Во-первых глюк с потреблением памяти. Как ни крути, но 300 метров под маленькую БД, это слишком дофига. Во-вторых, медленно. По сравнению с MS SQL очень медленно. После перевода базы на MS SQL скорость обработки данных возросла примерно на порядок. GP>Вот так вот.
Сразу и на MS SQL ... а если денег нет? Если разрабатывать на Дельфи -- то лучше выбрать в качестве СУБД бесплатный клон InterBase -- Firebird.
Здравствуйте, ironwit, Вы писали:
I>Значит, ситуация такова. I> Предприятие, в нем есть очень много отчетных форм (обычно excel), необходимо все отчетный формы "оцифровать". То есть, необходимо данные хранить в БД, юзерам давать возможность вводить те данные, которые касаются только их, руководителям видеть у себя полную информацию с возможностью анализа (диаграммы, схемы, сегодня <--> вчера <--> прошлый год). I> Само собой, этих форм немеренно, и их количество не собирается уменьшатся, поэтому кодировать каждую нет смысла. Необходимо создать какой то глобальный модуль. I> Может ли кто чего посоветовать? Аналоги, статьи... I> Разрабатываться будет на Delphi, БД скорее всего mysql, хотя это не принцпиально, так как я сам и постановщик и руководитель проекта.
I> Спасибо.
В формах содержаться данные ... если представить эти данные в виде объектов ... то можно попытаться использовать технологию, описанную в стстье "База данных -- хранилище объектов" (урла не помню ...) ... а отчеты -- как ни крути рисовать придется.
Здравствуйте, byur, Вы писали:
B>Здравствуйте, ironwit, Вы писали:
I>>Значит, ситуация такова. I>> Предприятие, в нем есть очень много отчетных форм (обычно excel), необходимо все отчетный формы "оцифровать". То есть, необходимо данные хранить в БД, юзерам давать возможность вводить те данные, которые касаются только их, руководителям видеть у себя полную информацию с возможностью анализа (диаграммы, схемы, сегодня <--> вчера <--> прошлый год). I>> Само собой, этих форм немеренно, и их количество не собирается уменьшатся, поэтому кодировать каждую нет смысла. Необходимо создать какой то глобальный модуль. I>> Может ли кто чего посоветовать? Аналоги, статьи... I>> Разрабатываться будет на Delphi, БД скорее всего mysql, хотя это не принцпиально, так как я сам и постановщик и руководитель проекта.
I>> Спасибо.
B>В формах содержаться данные ... если представить эти данные в виде объектов ... то можно попытаться использовать технологию, описанную в стстье "База данных -- хранилище объектов" (урла не помню ...) ... а отчеты -- как ни крути рисовать придется.
Уже началось реализовываться
Принцип таков. Таблица с наименованием окна ввода данных, связанная с ней таблица с описанием параметров, их типов, связанности с detail таблицами ..., таблица уже конкретно данных, в которой собственно все и хранится. Все формочки рисуются автоматом, на основе данных сидящих в БД (первых двух таблицах). Сейчас пытаюсь реализовать таким же типом и отчетную систему
