|
Вопрос # 3 382/ вопрос открыт / |
|
Приветствую, уважаемые эксперты!
Подскажите, что лучше выбрать за основу базу данных, если:
1. Количество и формат полей заранее неизвестны (поля могут добавляться в процессе развития проекта и расширения аппаратной базы самого проекта)
2. База должна работать в многопользовательском режиме
3. Конечный пользователь должен быть избавлен от администрирования этой базы.
 |
Вопрос задал: Виктор Киреев (статус: Посетитель)
Вопрос отправлен: 9 ноября 2009, 12:21
Состояние вопроса: открыт, ответов: 1.
|
Ответ #1. Отвечает эксперт: Вадим К
Здравствуйте, Виктор Киреев!
по пунктам
1) - плохое предположение. лучше подумать и избавиться от этого. хотя многие базы позволяют менять структуру, добавляя/удаляя поля.
2) firebird, MySQL - это из лёгких. MSSQL, Oracle - из тяжелого.
3) конечный пользователь не имеет права администрировать базу. от греха подальше. Или имеется ввиду, что база должна быть полностью автономной и не требовать постоянного вмешательства? Думаю, что в таком случае firebird и MySQL будут хорошим решением. По второму есть много литературы, есть много специалистов. Но если структуру базы захочется менять при каждом обновлении программы, то лучше отказаться от этой идеи. Потому что придется либо держать опытных админов, либо очень аккуратно тестировать обновление с одной версии на другую. Но всегда найдутся люди, которые перепрыгнут через версию и всё... пиши пропало.
Поэтому я бы делал так. Вначале хорошо подумал, потом ещё раз, потом взял бы MySQL за основу. Когда писал код, то выделил бы классы, которые напрямую работают с базой, но они должны быть оберткой - только они и должны работать с базой. В будущем, если окажется, что эта база неподходящая, надо будет только переписать пару классов.
 |
Ответ отправил: Вадим К (статус: Академик)
Время отправки: 9 ноября 2009, 12:42
Оценка за ответ: 4
Комментарий к оценке: Все верно, но, увы, есть проблемы... Не в ответе, в моем начальстве
|
Мини-форум вопроса
Всего сообщений: 7; последнее сообщение — 9 ноября 2009, 15:55; участников в обсуждении: 2.
|
|
Виктор Киреев (статус: Посетитель), 9 ноября 2009, 13:44 [#1]:
Виктор Киреев:
Спасибо, Вадим, за оперативный ответ. Вся беда в том, что уважаемому руководству невозможно ничего разъяснить касаемо пункта 1. Здесь управляет не логика, а "хочу!". Тестовая версия работала нормально, пока руководству не захотелось еще некоторые данные запихнуть в базу. Предвидеть, что еще надо будет складывать в таблицы и в каком формате спрогнозировать невозможно. Отсюда и вопрос. Получается, что структуру базы надо каждый раз переделывать.
|
|
|
Вадим К (статус: Академик), 9 ноября 2009, 13:57 [#2]:
если проблема в руководстве, то почему мне 4? или мне пойти с руководством разобраться?
что же делать? варианты:
- уволиться. Если начальство не знает, что хочет, то лучше уйти.
- рискнуть и написать всё на типизированных файлах.
- написать всё на xml. они могут помочь решить часть проблем.
- подумать, подойти к начальству и попросить более конкретное ТЗ.
- перестать ныть и тянуть это дело до победного конца.
Галочка "подтверждения прочтения" - вселенское зло.
|
|
|
Виктор Киреев (статус: Посетитель), 9 ноября 2009, 14:16 [#3]:
Извините, Вадим, но первый ответ был преимущественно очевидным. В размышлениях я тоже остановился на xml. Более того, базу данных тоже придется оставлять. Все, что может расширяться - в xml. Может посоветуете чего по работе с этим xml?
И касаемо второго ответа. Уже уволился бы, но тема интересная.
|
|
|
Вадим К (статус: Академик), 9 ноября 2009, 14:44 [#4]:
парсеров хмл - кучка. Я даже сам в свое время писал под себя sax парсер. если надо парсер - заходим на torry.net и ищем.
Хотя я вижу, пока рассуждаем об абстрактой задаче. может, если задача будет чуточку яснее, то может быть и готовый метод прицепить на нее сможем? а все эти "плачи" только от того, что решение неизвестно?
Галочка "подтверждения прочтения" - вселенское зло.
|
|
|
Виктор Киреев (статус: Посетитель), 9 ноября 2009, 15:28 [#5]:
Задача следующая. Имеется аппарат, в который заходит пациент. В аппарате исследуется величина отражения от кожи пациента света с разной длинной волны. По результатам подбирается режим воздействия цветным светом. У пациента до и после процедуры измеряют пульс на обеих руках, температуру в обеих подмышечных впадинах, артериальное давление на обеих руках, число дыханий. Все это измеряется в ручном режиме. Теперь администрации нужно автоматизировать этот процесс. Измерения должны проводиться до, во время и после процедуры. Интересует не только конечное значение, но и на интервале времени. Аппаратные расширения (те что на подходе и прогнозируемые): ЭКГ, оксигемометрия, сфигмометрия, исследование внешнего дыхания, термометрия с разных участков тела, исследование отражения с разных участков тела... А так же автоматизированный анализ жалоб пациента, его истории болезни...
По поводу "плача Ярославны" - просто не успеваю реализовать стратегическое решение проблемы.
|
|
|
Вадим К (статус: Академик), 9 ноября 2009, 15:40 [#6]:
Можно зделать оригинально. Часть полей, которые более-менее стабильны - имя, номер карточки и так далее - держать в базе. а вот для разных переменных полей, держать поле blob, в котором в виде xml/ini хранить переменные данные. После этого изменять структуру таблиц не надо будет, старые поля мешать сильно не будут, можно будет на каждого пользователя хранить свой набор данных.
Единственное, что придется уметь распарсивать такие данные и отображать. И чуточку усложниться поиск, но так как это текст - то это как бы и не проблема.
Галочка "подтверждения прочтения" - вселенское зло.
|
|
|
Виктор Киреев (статус: Посетитель), 9 ноября 2009, 15:55 [#7]:
Большое спасибо! Ваш совет действительно поможет решить мою проблему!
|
Чтобы оставлять сообщения в мини-форумах, Вы должны авторизироваться на сайте.
|
