БД для клиент-серверного приложения

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

Серверная часть должна работать с БД. Если представить БД как таблицу, то я думаю сделать из 4-х столбцов: в первом - дата, во втором - время, в третьем - сколько дорожек свободно и в четвертом - фамилия. Из этого ясно, что должен осуществляться поиск по дате и времени, и если количество свободных дорожек в заданное время больше 0, то можно заказать дорожку, и в БД добавить новую запись с датой, временем, фамилией и оставшимся количеством свободных дорожек.

Но проблема в том, что СУБД мы еще не изучали, а преподаватель требует, поэтому у меня много вопросов: какую БД в этом случае лучше использовать? Как осуществлять поиск по дате и времени? Как изменять в полях оставшиеся количество свободных дорожек в данное время?
Я уже много всякого начитался в интернете, но все-равно смутно себе все представляю. И я не прошу все рассказать от "а" до "я", просто помогите советом, примером, литературой, которую нужно прочитать. Может как-то по другому посоветуете базу сделать, в общем буду рад всем советам

0

Fireblade,

Сообщение от Fireblade в первом - дата, во втором - время, в третьем - сколько дорожек свободно и в четвертом - фамилия

Бред сивой кобылы.
Делите котлеты и мухи. Дорожки отдельно. Клиенты отдельно. И у вас не одна таблица должна быть. А еще у дорожек есть номера. Если я не хочу играть на 3 а хочу на 5.

Сообщение от Fireblade Но проблема в том, что СУБД мы еще не изучали, а преподаватель требует

Интересно, а это как вам надо решить задачу без знания териии БД?
Фактически это ни к чему не приведет. Ну разве что за вас кто нибудь это сделает.

0

Сообщение от rdama Fireblade, Бред сивой кобылы. Делите котлеты и мухи. Дорожки отдельно. Клиенты отдельно. И у вас не одна таблица должна быть. А еще у дорожек есть номера. Если я не хочу играть на 3 а хочу на 5. Интересно, а это как вам надо решить задачу без знания териии БД? Фактически это ни к чему не приведет. Ну разве что за вас кто нибудь это сделает.

Ну а как тогда лучше сделать базу? Еще добавить номер номер дорожки и поле занята она в это время или нет?
Преподу пофиг, он сам говорит, что типо образовательная программа плохая. Предлагает или самим изучать БД или же использовать типизированый файл.

0

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

0

Сообщение от Fireblade Преподу пофиг, он сам говорит, что типо образовательная программа плохая

Нутогда ему нечего делать в универе. Если он свой же курс не может наладить. И дать вам задачи в соответсвии с тем что он вам преподавал. А раз уж он знает что будут такого рода задачи,то мог бы выделить пару зройку лекций и на пальцах объяснить основы.

Сообщение от Fireblade самим изучать БД

Ну конечно так ведь проще. А свою зарплату он вам тоже предлагает самостоятельно освоить или все же...

Сообщение от iifat СУБД, СУБД... Помешались все на этих СУБД.

Причем здесь это-то. Задача поставлена так как поставленна. И подразумевает определенное решение. Для изучения и закрепление определенного набора знаний и навыков.
В данном случае проблема в том что задача дана неподготовленному лицу, который без необходимого мимнимума эту задачу решить не сможет. Времени на изучение этого минимума как всегда нет. Вот и получается то что получается.
А СУБД или файл или таблички в памяти или объекты в памяти это уже не столь важно. Опять же даже при реализации на типизированном файле ты разделишь мух и котлеты по признакам в соответствии с принципами ООП независимо от уровня твоих знаний.
А когда ты знаешь о написании программ лишь набор операторов и что делфи запыскается с ярлычка с цифиркой 7.
То результат будет плачевным.
Для ТС можно рекомендовать прочитать основы реляционных БД и их проектирования. Большое внимание к нормализации отношений.
Ну и далее пытаться создать БД и милости просим к нам с вопросами о конкретных трудностях при реализации.
Конечно можно вам собрать БД и отдать,но что вы с ней сможете сделать? Если как я понимаю у вас и навыков работы с БД при реализации интерфейса в Delphi тоже нет.

0

Как я понял ТС, задача -- клиент-сервер. БД там не упоминается. Либо я неверно понял, либо таки двоичный файл для простой базы проще, чем изучать теорию реляционных БД.

0

Сообщение от Fireblade создать клиент-серверное приложение

О каких

Сообщение от iifat либо таки двоичный файл

речь идет. Я боюсь представить как ТС будет разбираться с блокировками файла при одновременной работе некольких клиентов. Как будет реализован механизм записи в этот файл при одновременной работе. Каким образом 2 клиент будет узнавать о том что некая дорожка занята.
В вашем случае при реализации задачи придется идти либо путем многозвенной архитектуры (клиент(интерфейс) - сервер(логика) - файл(хранение)) либо частично писать свою СУБД которая будет работать с вашим типизированным файлом (Клиент(интерфейс, логика) - сервер БД(управление клиентскими сессиями основной функционал записи/чтения/блокировок/очередей доступа и т.п - файл(хранение))). Это при условии что вся логика по управлению блокировками, очередями записи и изменениями будет вынесена в отдельное приложение.
Ну и так для разгона Клиент-сервер
В вашем случае при работе с файлом и реализации всего мной описанного это будет скорее файл серверная архитектура.
В плане что вся логика реализуется на клиенте.
Так что как-то так.

0

Сообщение от rdama Я боюсь представить как ТС будет разбираться с блокировками файла при одновременной работе некольких клиентов. Как будет реализован механизм записи в этот файл при одновременной работе. Каким образом 2 клиент будет узнавать о том что некая дорожка занята.

Опомнись, человече! Какие блокировки? Какой механизм записи? Какая многозвенная архитектура?
Один файл. Один сервер. Запустился, прочитал, ждёт клиентов.
Дождался, выполнил запрос, ждёт следующего.
В конце -- пишем из памяти всё обратно в файл.
Задача -- учебная. Да хоть и реальная: объём базы -- какой? Я не знаком с работой боулинга, мож, глупость скажу. К примеру, 20 дорожек. Заказы по времени, кратные, скажем, 15 минутам. К примеру, 1000 клиентов (впрочем, справочник клиентов -- опять же, для учебной задачи -- можно и не делать). К примеру, на пару недель вперёд. Неужто в пару мегабайт не уложится?
Вот это:

Сообщение от rdama Каким образом 2 клиент будет узнавать о том что некая дорожка занята

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

0

Сообщение от iifat Один файл. Один сервер. Запустился, прочитал, ждёт клиентов.

Ну т.е. 3 звенка.

0

Сообщение от rdama Ну т.е. 3 звенка

Трёхзвенка -- если добавить клиент-серверную СУБД (не обязательно SQL). Если сервер сам читает файл и отвечает на запросы -- где тут третье звено?

0

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

0

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

0

У SQLite и Access тоже нет. И тем не менее.

0

Тем не менее -- что? Если сервер работает с базой на SQLite/Access, то мы имеем трёхзвенку? Мы, похоже, очень по-разному понимаем эту самую трёхзвенку. Лень, честно говоря, искать, кто из нас прав. Хай будет трёхзвенка.

0

Сообщение от iifat Тем не менее -- что?

И то и другое СУБД.
В принципе я чего то тоже запутался.
А как рассматривать вариант 1С клиент - платформа - файловая БД?

0

Ну, я как-то считаю звеном отдельный процесс. Файловая БД отдельного процесса не запускает.
Хотя, вполне возможно, стоит считать асинхронные эээ... сущности, что ли. Тогда даже асинхронно читаемый файл -- звено. 1С 7 версии вообще одним процессом, как я понимаю, работает, 8 в руках не держал. Если вернуться к нашим баранам, я предлагал именно синхронное одноразовое чтение файла при запуске. А вот, к примеру, Access, да через асинхронные запросы -- ну, может, и заслуживает называться звеном.

0

Сообщение от iifat Трёхзвенка -- если добавить клиент-серверную СУБД (не обязательно SQL). Если сервер сам читает файл и отвечает на запросы -- где тут третье звено?

а третье звено это слабое звено)))
под такую задачу лучше использовать MySQL))) для клиент-серверную не ставят онлайн...слишком уязвимо...да и защита в копеечку влетит)))

0

Сообщение от gosean под такую задачу лучше использовать MySQL

Будь эта задача реальной -- был бы, возможно, смысл использовать MySQL, а то и лучше SQLite. Всё, что я говорю -- я говорю про случай учебной задачи и ТС с нулевыми знаниями БД и недостатком времени.

0

iifat, я про 7 не говорю. Сугубо о восьмерке. У нее есть возможность работы в таком режиме.
Ну т.е мы приходим к синхронному чтению. И по факту получается некое подобие реализации проекта на DataSnap'е.
Сервер один раз при запуске открывает наш файл и сидит с ним, пока клиент ему не пришлет запрос для каких нибудь манипуляций с данными.
Необходима реализация управления сессиями и очередями записи. Ибо на лицо конфликт "кто последний тот и папа". Хотя зависит от реализации.
Кстати технология DataSnap как раз для построение многозвенных архитектур.
В случае с Access и SQLite у нас есть такое понятие как ядро СУБД Jet в случае Access и sqlite.dll во втором случае.
Т.е. условно можем считать 3 звенкой. Хотя по факту вроде как файл-сервер.
В нашем случае если мы реализуем весь функционал по интерпритации запросов клиента в серверном приложении , то вроде как и 2 звенка получается, а если мы вынесем логику в отдельную библиотеку и будем юзать функции из нее то уже вроде как появляется некий драйвер для работы с нашим файлом. В общем офтоп страшный,но с целью разобраиться. Как интерпритировать такой архитектурный прием.
gosean, онлайн тут не причем это всего лишь термин указывающий на то, что система должна работать в реальном времени. Т.е. если один клиент занял дорожку, то второй ее занять уже не может.
В принципе если мы реализуем функционал по управлению сессиями, то есть возможность от сервера отправлять команду на обновление каждому клиенту. С целью показать, что дорожка уже занята.
И кстати в 1С 8 до сих пор существуют проблемы блокировок.

0

Трехзвенка
БД-Сервер-Клиент

0