Как организовать структуру базы данных для небольшого приложения?

Question

[Дмитрий Борисенко]

Здравствуйте! Прошу меня извинить, если вопрос покажется вам глупым, а ответ банальным. Я врач. Создание небольших прикладных программ на Java для меня хобби и подспорье в работе для меня и моих коллег. Опыта работы с базами данных нет. Столкнулся со следующей небольшой проблемой.
Делаю программу для контроля прихода и расхода трансфузионных сред (ТС) и оформления протоколов использования и списания. Нужна база данных для хранения параметров нескольких различных ТС. Параметры следующие (как минимум): 1) объем ТС, 2) код, 3) срок годности и 4) точное название. Имеется 8 вариантов групп крови.
Сделал это следующим образом. Для каждой разновидности ТС свой текстовый файл (хотя это практически .csv-файл). В файле следующая структура: 8 строк; в каждой строке через запятую сначала идут объемы, затем коды ТС, затем срок годности. Например:
345,500,420,111111111111,222222222222,333333333333,12052018,09022018,06012018
.........
245,777777777777,18022018
Все эти данные считываются в 3-мерный массив, где 1-ая размерность вариант группы крови, 2-ая - объем, код и срок.
Подозреваю, что можно сделать намного проще!)))
Если да, подскажите как. Буду очень благодарен за помощь!

Comments

[Дмитрий Борисенко]

Здравствуйте, ID_CLASSNAME! Спасибо за отклик.

Здравствуйте, Роман Мирр!
Спасибо за ваш отклик!) К сожалению, не увидел ваш ответ на мой вопрос сразу (как раз из-за того, что основная профессия - врач и у меня просто не было времени). С базами данных MySQL и SQLite я пока работать не умею (но это только пока!), поэтому и пришлось пойти столь извилистым и нерациональным путем.

Почему в 1-й строке 9 значений, а в 3-й лишь 3?

Потому что в 1-й строке 3 пакета эрвзвеси 0(I) Rh+ объемами 345, 500 и 420 мл с соответствующими им 3 кодами донации и 3 сроками годности, а в 3-й (точнее, в последней) лишь один пакет эрвзвеси AB(IV) Rh- объемом 245 мл с соотв. кодом донации и сроком годности.

Все эти данные считываются в 3-мерный массив
Есть ощущение, что это излишнее пересложнение. Я думаю это вряд ли это имеет что-то общее с линейной алгеброй.

Сначала и был 2-мерный, но потом удобнее оказался именно 3-мерный (проще из-за структуры самой программы, которая тоже скорее всего неидеальная (я имею в виду структуру, так как программа идеальна по определению! ;) ).
В принципе, все заработало как надо. Программой уже можно пользоваться, но всплыли некоторые другие проблемы, небольшие, но докучающие. И если у вас есть такая возможность, Роман, не могли бы вы подсказать направление решения этих проблемок? Просто гораздо полезнее для нуба, если ему скажут не что-то вроде: "Двигай куда-нибудь на восток или на юго-восток, и по дороге спросишь", как сделал уважаемый ID_CLASSNAME, но хотя бы тропинку покажут, как попытались сделать вы!)
Вопрос я задам в соответствующей ветке. Он касается кодировки при выводе в файл.
Спасибо еще раз за помощь!

[d'Ivan]

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

[Дмитрий Борисенко]

Роман Мирр, спасибо!

Answer 1

[d'Ivan]

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

345,500,420,111111111111,222222222222,333333333333,12052018,09022018,06012018
.........
245,777777777777,18022018

345,500,420 - это наверно v1, v2, v3 (v - volume, тип integer)
111111111111,222222222222,333333333333 - это наверно te1, te2, te3 (te - transfusion environment, тип integer)
12052018,09022018,06012018 - это наверно ed1, ed2, ed3 (ed - expiration date, тип Date)
Затем в 3-й строке примера
245 - это наверно v1
777777777777 - это наверно te1
18022018 - это наверно ed1

Если я верно понял, в каждой строке CSV может храниться разное количество столбцов, в зависимости от типа ТС. Это так?
Почему в 1-й строке 9 значений, а в 3-й лишь 3?
Можно ли заранее знать сколько значений в некоторой строчке? Или для этого нужно прочесть все значения поочередно в заданной строке?

Всю эту кашу с данными нужно понять с точки зрения:

• типов данных
  
• размерности каждого типа данных
  
• зависимости одного типа данных от другого
  

Все эти данные считываются в 3-мерный массив

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

По-моему, на 99% имеются более оптимальные решения по работе с вышеприведёнными данными.
В первую очередь, формат CSV не годится для хранения векторов данных разных длин (переменного количества столбцов). Во-вторых, он не годится в качестве БД. Обычно CSV является промежуточным форматом для обмена информации, но не более того. Вместо CSV стоило взять реляционную СУБД (MySQL, Firebird, SQL Server Express).
А если система однопользовательская и не нужна авторизация пользователей, то вообще достаточно СУБД SQLite (через интерфейс JDBC), файл БД которой представляет из себя единичный файл .sqlite.

P.S.
И когда же у вас получается находить время программировать? :-o

Comments

[d'Ivan]

cattom72 дополнительно:
Хранение данных: CSV или БД?