Наши проекты:
Журнал · Discuz!ML · Wiki · DRKB · Помощь проекту |
||
ПРАВИЛА | FAQ | Помощь | Поиск | Участники | Календарь | Избранное | RSS |
[3.16.212.99] |
|
Данный раздел предназначается для обсуждения вопросов использования баз данных, за исключением составления запросов на SQL. Для этого выделен специальный раздел. Убедительная просьба - соблюдать "Правила форума" и не пренебрегать "Правильным оформлением своих тем". Прежде, чем создавать тему, имеет смысл заглянуть в раздел "Базы данных: FAQ", возможно там уже есть ответ. |
Страницы: (4) [1] 2 3 ... Последняя » все ( Перейти к последнему сообщению ) |
Сообщ.
#1
,
|
|
|
Доброго времени суток, уважаемые форумчане!
Я работаю Вооруженных Сил РФ. Учет личного состава ведётся на бумажных носителях. Для автоматизации учета хочу создать базу данных, удовлетворяющую следующим требованиям: 1. У военнослужащего имеется около 90 параметров (учетных данных). 2. Большинство из параметров (учетных данных) представляют собой сложные структуры (например, в полях «дети» необходимо содержать такую информацию как ФИО, пол, дата рождения, свидетельство о рождении и т.д. 3. Хранение записей по нарастающей хронологии, т.е. хранить сведения обо всех детях, датах и номерах приказов о присвоении званий, назначении должностей, периодах службы и т.д. 4. Возможность вывода любых форм (отчетов) в различных комбинациях параметров (учетных данных) и подсчёт всевозможной статистики. 5. Вывод форм (отчетов) в документы MS Word и Excel. 6. БД несетевая, но мобильная: быстрый перенос (копирование) БД через флеш-носители на компьютеры, несвязанные между собой сетью. Вопросы: 1. Какую модель данных (технологию, парадигму программирования) выбрать? Реляционную, объектно-ориентированную или что-то иное? 2. Возможно ли реализовать требуемую БД в MS Access или 1С? 3. Какую литературу посоветуете по реализации моей БД? Заранее спасибо. Прошу прощения, если ошибся в терминах. БД изучал в университете 5 лет назад. |
Сообщ.
#2
,
|
|
|
Цитата flintpit @ Реляционную, объектно-ориентированную или что-то иное? Реляционную + объектно-ориентированную. Цитата flintpit @ 2. Возможно ли реализовать требуемую БД в MS Access или 1С? Можно, но как быть с Цитата flintpit @ но мобильная: быстрый перенос (копирование) БД через флеш-носители на компьютеры Одно из требований это установленный офис и 1С. Цитата flintpit @ 2. Большинство из параметров (учетных данных) представляют собой сложные структуры (например, в полях «дети» необходимо содержать такую информацию как ФИО, пол, дата рождения, свидетельство о рождении и т.д. Дети это такие-же физ лица что и родители только у них должен стоять признак что они дети (отдельная таблица). Точно также и родственники военнослужащего, тети ,дяди и остальные кузины и ..... Если отец и мать тоже военнослужащие и у них общие дети, вы же не будете вводить одного и то же ребенка дважды. Достаточно дать ссылку на физ.лицо и установить признак ребенка. Добавлено Так и с остальными структурами, типа место жительства, образования и тд и тп |
Сообщ.
#3
,
|
|
|
Поставленная задача на самом деле требует не столько внимания к организации хранения данных (все озвученные данные можно хранить хоть в plain text или там XML, это несильно скажется на производительности с учётом прогнозируемых объёмов данных), сколько к интерфейсной части (создание необходимых обработок и генерации выходных форм, в т.ч. экспортируемых).
С учётом этого настоятельно рекомендую забыть про одноэску. MS Access в принципе неплох - но возникнут озвученные выше проблемы с необходимостью наличия установленного офиса, причём именно в Проф версии, ибо в стандарте Акса тупо нет, плюс определённые сложности в связи с отсутствием штатных средств резервирования и наличием ограничений на размер БД (с учётом того, что файл БД одновременно используется и как файл-кэш для материализации промежуточных данных). Однако я бы предложил посмотреть в сторону альтернативных инструментов, которые специально затачиваются именно под создание связки БД+интерфейс, но при этом сами портабельны (только интерфейсный обработчик либо комплекс с БД) и содержат более вменяемый встроенный сервер БД. Например, типа MyVisualDatabase (она бесплатна для некоммерческого использования). |
Сообщ.
#4
,
|
|
|
Сперва небольшое отступление. Последние 2 с половиной года разрабатывал АРМ центра социального обслуживания населения. Как оказалось впоследствии, именно грамотное построение структур учета - основной головняк разработки. Не последующие регистрации работ/консультаций/обслуживаний, а именно регистрация и учет граждан... И мне есть чего сказать
Цитата flintpit @ Вопросы: 1. Какую модель данных (технологию, парадигму программирования) выбрать? Реляционную, объектно-ориентированную или что-то иное? Строго реляционную. Потому, как с помощью этого решаемо на 100%, потому как более широко используемо, потому как больше кому будет помочь советом. Цитата flintpit @ 2. Возможно ли реализовать требуемую БД в MS Access или 1С? Возможно. Но с этими двумя на практике не знаком, без комментариев. Цитата flintpit @ 3. Какую литературу посоветуете по реализации моей БД? Сперва искать ликбез по проектированию реляционных БД. Ну а теперь "вкусненькое" ... Типа броне-костюм для строевой подготовки на минном поле 1) "Реляцоинность" данных! Без этого в будущем будут невзгоды и лишения, которые, согласно присяге, вам нужно будет преодолевать. А оно надо вам? Простой пример. Общеупотребимая практика. Для учета граждан создается основная таблица, состоящая из множества полей типа VARCHAR - ФИО, Адрес проживания, иногда и телефон ... Но, и фамилии меняются, и адреса, и телефоны. Со временем. А вам нужно что? Вместо этого собираем наши информационные сущности как из "конструктора". а) Создаем каталог "Описателей", типа: ID - уникальный идентификатор Name - название (используемое в UI), например ФАМИЛИЯ Prompt - короткая подсказка Help - длинный хелп по назначению и способу заполнения Type - тип данных (INT,FLOAT,VARCHAR) либо ссылки на рубрики, на сущности, ... тут нужна фантазия б) Создаем каталог "Информационных сущностей", типа: ID - уникальный идентификатор Name - название сущности (используемое в UI), например "КАРТОЧКА ВОЕННОСЛУЖАЩЕГО" c) Создаем каталог "Конструкторов Информационных сущностей", типа: ID - уникальный идентификатор Target - ссылка на б) Info - ссылка на a) Cost - желаемый порядок размещения в UI Что в результате? В результате вместо статической структуры, известной на момент сборки - получаем возможность строить нужные нам динамические структуры на момент ввода в эксплуатацию, равно как и во время самой эксплуатации. Нужно нам 90 полей - пожалуйста, нужно 91-е поле, нет проблем - решается администрированием путем создания (при необходимости поля) и "привязки" его к нужной информационной сущности. 2) "Версионность" данных! Вот оно самое: Цитата flintpit @ Хранение записей по нарастающей хронологии Как в "Карточке военнослужащего" правильно изменить описатель "Образование"? Правильно, нужно создать таблицу "Актуализация", типа: Id - уникальный идентификатор Date - дата изменения Type - тип изменения Rel - ссылка на новое значение Cause - ссылка на рубрикатор причин Note - коментарии Таким образом, наша сборная карточка в последствии будет иметь версионность в виде цепочки изменений. Каждое из которых можно отследить по времени и по исполнителю (об этом ниже). 3) "Журналирование" данных! Каждую операцию нужно журналировать. "Кто-что-когда". Это позволит в будущем делать и анализ работы учетных подразделений, и позволит, при необходимости делать откаты изменений. Ну естественно, не нужно путать принцип "Бритвы Оккама" с неоправданным упрощением информационных моделей. По поводу "движка БД" - посоветую глянуть в сторону SQLite. Сам с ней не работал, но в планах - намереваюсь. Удачи! Добавлено Вдогоночку. Забыл упомянуть про "Отчетность". Давно надумалось неплохое решение - если хранить отчеты, их UI-входные формы и выходные формы, в самой БД. Нет проблем не только для M$ Access! Простой пример. Сам интерфейс пишется на Qt/C++ , а отчеты хранятся в БД в виде VARCHAR, содержащие скриптовые подпрограммы на QtScript. Переработка отчетности совсем не потребует переработки программы. Более того, идеально решается вопрос дистрибуции изменений в отчетности. |
Сообщ.
#5
,
|
|
|
Цитата JoeUser @ Забыл упомянуть про "Отчетность". "Отчетность"- выделить в отдельную тему, так как она многогранна и многолика (по способам хранения, сборки , визуализации)? Если будет обсуждение развиваться. Добавлено Цитата JoeUser @ Сперва искать ликбез по проектированию реляционных БД. поиск по форуму |
Сообщ.
#6
,
|
|
|
Как удалить неправильно написанное сообщение?
Добавлено Как удалить неправильное написанное сообщение? Добавлено Цитата JoeUser @ Вместо этого собираем наши информационные сущности как из "конструктора". а) Создаем каталог "Описателей", типа: ID - уникальный идентификатор Name - название (используемое в UI), например ФАМИЛИЯ Prompt - короткая подсказка Help - длинный хелп по назначению и способу заполнения Type - тип данных (INT,FLOAT,VARCHAR) либо ссылки на рубрики, на сущности, ... тут нужна фантазия б) Создаем каталог "Информационных сущностей", типа: ID - уникальный идентификатор Name - название сущности (используемое в UI), например "КАРТОЧКА ВОЕННОСЛУЖАЩЕГО" c) Создаем каталог "Конструкторов Информационных сущностей", типа: ID - уникальный идентификатор Target - ссылка на б) Info - ссылка на a) Cost - желаемый порядок размещения в UI 2) "Версионность" данных! Вот оно самое: Цитата flintpit @ Хранение записей по нарастающей хронологии Как в "Карточке военнослужащего" правильно изменить описатель "Образование"? Правильно, нужно создать таблицу "Актуализация", типа: Id - уникальный идентификатор Date - дата изменения Type - тип изменения Rel - ссылка на новое значение Cause - ссылка на рубрикатор причин Note - коментарии Спасибо за столь развернутый ответ. Обязательно использую. Но откуда эти строки кода? Какой язык? Изучал С++, РНР, SQL, но эти не знакомы |
Сообщ.
#7
,
|
|
|
Это не "язык". Это описание структур в принципе. А на чём его реализовать - дело десятое.
|
Сообщ.
#8
,
|
|
|
Проанализировав множество советов на различных форумах, пришел к решению строить простейшую базу в МS Access. В качестве теории выбрал Хомоненко «Базы данных» (2004), по которой учили в универе, знакомый текст лучше вспоминается, да и сама книга написана на основе зарубежной литературы. В помощь для разъяснения сложных вопросов взял Дейта «Введение в системы баз данных» (2005), которого все рекомендуют, и Крёнке «Теория и практика построения баз данных» (2003) из вызывающей доверие серии «Классика computer science» издательства Питер.
В качестве практического руководства по MS Access взял Сеннова и Гурвица. Всем спасибо за ответы! |
Сообщ.
#9
,
|
|
|
Цитата flintpit @ Зря... Акцесс хорош для домашней библиотеки. Но никак не подходит для твоего случая. пришел к решению строить простейшую базу в МS Access ЗЫ - в его SQL-коде даже комментарии нельзя вводить!!! Рекомендую зарегистрироваться на Oracle, скачать то, что тебе нужно (а не обломки с пиратских торрентов) и пользоваться возможностями полноценного СУБД-движка (лицензия для твоих целей ИМХО вообще не нужна). --- ЗЗЫ - а в части обмена - Oracle DataPump в помощь. Не так быстро, как замена одного ACCDB на другой, но и не так критично по времени. У тебя не СУБД реального времени (не телефонная компания)! |
Сообщ.
#10
,
|
|
|
Цитата #SI# @ Рекомендую зарегистрироваться на Oracle, скачать то, что тебе нужно (а не обломки с пиратских торрентов) и пользоваться возможностями полноценного СУБД-движка (лицензия для твоих целей ИМХО вообще не нужна). А теперь расскажи, как с твоим советом предлагается воплощать исходное требование Цитата flintpit @ БД несетевая, но мобильная: быстрый перенос (копирование) БД через флеш-носители на компьютеры, несвязанные между собой сетью. Причём не в части переноса данных (DataPump с этим действительно справится), а в части переноса сервера БД, без которого нихренашеньки не станет работать. Не припоминаю я существования у них встраиваемого сервера что-то... да и для невстраиваемого аппаратная конфигурация должна быть, скажем прямо, нетривиальная, что в реалиях ВС РФ наличествует далеко не везде... |
Сообщ.
#11
,
|
|
|
Akina, не думаю, что речь идёт о БД командира отделения. А вот на уровне части (военкомата етс...) - твой вопрос несущественен.
ЗЫ - хотелось бы знать, что реально написано в ТЗ на разработку. |
Сообщ.
#12
,
|
|
|
#SI#
Я думаю, что это личная (возможно, и общественная, но никак не официальная) инициатива низовых работников. Которые задолбались работать в бумаге. Более того - почти убеждён, что это так. И, следовательно, ни о каком ТЗ речи не идёт. Зато идёт речь о максимально простых и доступных, в т.ч. по освоению и углублённому изучению, средствах разработки - причём строго локальных, а не визуально-облачных. И в этом смысле Access как бы не в тройке (ну или во всяком случае в группе) лидеров. |
Сообщ.
#13
,
|
|
|
Как "карманный" вариант, думаю, потянет такое решение: Using MySQL on a Raspberry Pi. Конечно на старте будет непросто, нужно будет много чего осваивать параллельно, кроме SQL и проектирования реляционных БД. Но, по идее, может получится конфетка. Этакая биг-флэшка с дисплеем
|
Сообщ.
#14
,
|
|
|
Цитата Akina @ есть почти у всех нахаляву. В составе пиратского офиса . С этим - согласен.<...ППКС...>причём строго локальных, а не визуально-облачных. И в этом смысле Access Но для ЭТОЙ конкретной задачи Акцесс НЕ ГОДИТСЯ! ИМХО! Добавлено Цитата JoeUser @ Идеальный вариант. Но, похоже, ТС этим будет заниматься в свободное от основной работы время... Этакая биг-флэшка с дисплеем |
Сообщ.
#15
,
|
|
|
Цитата #SI# @ для ЭТОЙ конкретной задачи Акцесс НЕ ГОДИТСЯ! ИМХО! Категорически не согласен. На моей памяти (лет эдак 15 назад было) эксперт-криминалист самостоятельно, практически в одиночку, создал на Аксессе вполне работоспособную БД для фиксации, накопления и анализа результатов экспертиз. В начале работы он с трудом использовал Эксель. Через 2 года у него приложение было полностью работоспособно. Среднее количество атрибутов на первичную сущность - штук 30-40, количество типов первичных сущностей - порядка 20, количество выходных форм - с полсотни, автоматизированных обработок штук 5... Глаза боятся, а руки - делают. И даже если в конце концов ТС придёт к выводу, что Access как инструмент для его задачи не очень удачен, он успеет накопить достаточные знания и опыт, чтобы реализовать следующую версию на более "продвинутых" средствах. |