Какую СУБД лучше выбрать, какие методы для создания структуры базы данных применить, как устроить таблицы… ?

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

tygraДык есть такие. 1С. Аксапта. И Т.Д.


1С - это бухгалтерия. Зачем мне план счетов, накладные, договора, когда надо организовать учет успеваемости студентов.
На счет Аксапты, мелко плаваю, не пробовал, только читал.


tygra не может быть в природе
Не может быть, потому, что не может быть?

Пример из другой области.

Задачу по математике для 5-го класса о велосипедисте и мотоциклисте, которые ездят по дороге между пунктами А и Б, можно решить «в лоб», а можно формальным методом. В первом случае строим головоломки, графики и решаем, Если не получится, то обратимся к консультанту, более сильному математику. Во втором, используем систему линейных уравнений: выражаем одно через X, другое через Y, а далее - дело техники. Элементарно, если можешь решить систему линейных уравнений и умеешь привести к ней задачу, т.е. формализовать.

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

СерегаВот кухарки так и не научились управлять государством. А как готовили!!! Пальчики оближешь.
Ну это мы еще посмотрим. Разве можно судить по двум-трем неделям?

А если серьезно, то Вот выдержки из статьи

Задачи учета и обработки информации в управленческой деятельности предприятия имеют разные цели, разные методы обработки, разные формы представления результатов. Одна и та же задача на разных предприятиях или даже на одном, но выполняемая разными людьми, имеет различный внешний вид. Стремление найти закономерности в их описании похожи на попытки найти закономерности в китайских иероглифах. Можно отметить общность в различных элементах иероглифов, но не правила в их написании, как в письменности, основанной на строгом алфавите.

Проведем аналогию между задачами управленческого учета и физическими материалами. Бесконечно большое разнообразие материалов в своей физической природе описывается ограниченным количеством элементарных частиц, определенным образом увязанных между собой. Следуя этой аналогии, представим каждую управленческую задачу в виде объекта учета, как совокупности взаимосвязанных однородных элементарных объектов. Такие элементарные объекты должны обладать свойствами, необходимыми для решения всех задач управленческой деятельности, с одной стороны, а состав и характер этих свойств должен быть одинаковым для всего множества решаемых задач, с другой.

Рассматривая элементарный объект (ЭО) в статическом состоянии, необходимо и достаточно описать: идентификацию, состояние, внутренние связи. Идентификация элементарного объекта требует уникального ключа, однозначно определяющего ссылку на данный ЭО в пределах всего объекта учета. Требование наличия уникального ключа не зависит от объекта учета. Состояние элементарного объекта описывается набором параметров. Этот набор зависит от объекта учета. Например, ЭО в учете материалов включает параметры цена, количество, сумма. Параметры элементарных объектов удовлетворяют следующим двум требованиям: 1-состав параметров общий для всех ЭО одного объекта учета, 2 - параметры одного ЭО не зависят от параметров других ЭО. Не соблюдение любого из этих свойств означает неправильное определение элементарного объекта.

Внутренние связи элементарных объектов отражают функциональные зависимости между параметрами ЭО. Например, при учете материалов параметр «стоимость» равен произведению параметров «цена» и «количество». Внутренние связи одинаковы для всех ЭО одного объекта учета. Если это правило нарушается, то это означает, что не правильно определен объект учета. Он должен быть разделен на части для обеспечения данного правила. В общем случае параметры элементарного объекта объединяются в группы, каждая из которых предназначена для описания какой-либо отдельной стороны учета объекта. Выделение групп имеет смысл для упрощения процедур расчета параметров элементарных объектов.

Внешние связи элементарных объектов определяют принадлежность ЭО к различным группам, объединяющим их по различным факторам. Примерами факторов являются группы материалов, подразделения предприятия, адреса города. Набор факторов определяется для каждого объекта учета. Факторы имеют древовидную структуру. Каждая точка дерева предназначена для заданной точки учета. Висячая вершина дерева соответствует наибольшей детализации описания объекта. Связь фактор – элементарный объект - это значение висячей вершины фактора учета, приписанное ЭО. В общем случае применяется многомерный анализ, т.е. учет объекта одновременно по нескольким факторам. Каждый ЭО имеет столько параметров внешних связей, сколько факторов принято для объекта учета. Разделение параметров элементарных объектов на три группы позволяет разделить задачи автоматизации задач учета также на три соответствующих группы:
состав элементарных объектов
описание состояние объекта
выборка объектов по факторам учета.

Метод и, следовательно, и программное обеспечение для поддержки состава элементарных объектов, общие для всех объектов учета, так как ЭО имеют одинаковые параметры идентификации. Учет внутреннего состояния ЭО определяется внутренними параметрами, свойствен данному объекту учета и не зависит от других объектов. Вследствие этого методы работы с внутренними параметрами ЭО являются локальными для каждого объекта. Отсутствие связей с внешними объектами определяет простоту их разработки и поддержки. Методы выборки элементарных объектов по факторам учета являются общими для различных объектов в силу однородности внешних связей элементарных объектов.

На основе изложенных свойств элементарных объектов и классификации задач можно сделать следующие выводы:
1. Структура базы данных для учета элементарных объектов одинакова для всех управленческих задач учета в части идентификации ЭО, объединения ЭО в группы и отличается только набором внутренних параметров.
2. Программное обеспечение одинаково для всех управленческих задач учета в части поддержки состава элементарных объектов, формирования различных выборок ЭО по факторам учета, и локальное, т.е. не зависимое от других объектов учета в части сбалансированности внутренних параметров ЭО.

Так еще и Элементарные операции .

Какие есть мнения на этот счет?

aleks2
Готовые решения стоят денег.
Некоторым не хватает, другие хотят сэкономить.
Готовые решения труднее дорабатывать из-за их объема.
... и т.д. и т.п.
Готовых решений много - какое готовее?

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

aleks2А, вообще, откуда беруться готовые решения?
Я интересуюсь именно этим направлением. Где же еще, как не на этом форуме быстрее всего узнать о том, откуда могут взяться такие решения? Или получить железные аргументы о не перспективности такой затеи?

СерегаПо моим наблюдениям срок уже к столетию приближается.
А кто из домохозяек стал руководить страной 100 лет назад?

LSV Эта методология называется "теория реляционных БД". :)
Если по уму спроектируете, то и воспользоваться ею сможете разнообразнее. По уму, это так относительно. Сегодня так доволен своей разработкой, а через пару лет смотришь на нее и думаешь: «Как я мог так сделать? Ведь можно было решить по другому, элементарно.»

LSV Но кроме умения проектировать РСУБД нужно глубоко знать конкретную область автоматизации. И не иначе. Так ведь, если копнуть очень глубоко в эту предметную область, то оказывается, что всю задачу автоматизации можно разделить на отдельные части, которые по своей сути построения одинаковы.

LSV Совсем уж универсаных БД нет в природе, если конечно не считать WORD/EXCEL/RAR :) Так я не говорю об абсолютно универсальных базах данных. Я говорю о базах данных для некоторого класса задач. Кроме того, не о всей базе данных, а о ее системной части: составу основных таблиц, системной части таблиц, индексов, взаимосвязей и др.

LSV Теоретические размышления на тему "универсальных баз знаний" тут не причём. Практика гораздо прозаичнее... :) Конечно, практика – это критерий теории. Но практика без теории, это …

aleks2
Опыт Ъ показывает - никакая база не пригодна для широкого круга задач.
Иначе откуда их столько... разных?
------------
Ибо круг задач бесконечен, а количество баз конечно.
Например, задача «Складской учет» одна, а баз тысячи или десятки тысяч?

aleks2
Возможно, существует теория, что можно создать всеобщую методологию - дождетесь ли только? Почему «мы должны ждать милости от кого то (в оригинале от природы ), взять ее у нее – наша задача» (Мичурин)

aleks2Это только кажется, что задача «Складской учет» одна... перекрестись и все пройдет.
Сколько складов - столько учетов. Я не верующий. Меня можно убедить в обработном, если, например, привести две таких задачи, для которых нельзя было бы применить то решение, которое я использую в своих работах.

aleks2Кроме того всегда есть возможность сделать лучше.Лучьшее - враг хорошого. Достаточно, что бы решение удовлетворяло потребности пользователя.

Я не говорю про одну и ту же базу данных для всех задач. Речь идет о том, что если существуют закономерности при описании объектов учета и операций над ними, то существуют и закономерности в построении структуры базы данных. Закономерности выражаются в состоянии элементарных объектов и в учете элементарных операций. Из закономерностей вытекает одинаковый состав таблиц, одинаковые индексы и связи между таблицами и, следовательно, одинаковые методы обработки – значит один и тот же интерфейсный модуль для работы с разными задачами.
Конечно, разные объекты отличаются набором параметров. Но эти параметры имеют локальные функциональные зависимости, т.е. внутри объекта учета. Следовательно, настройка системы в основном состоит в настройке локальных параметров и взаимосвязей между ними. «В основном», потому что изменение состояния параметров одного объекта учета может вызвать синхронное изменение параметров другого, связанного объекта.