ABariyКак это всё упростить?

Вот-вот. Все эти советы с отдельными операциями - это все путь к смерти софта.

1) Не стоит делать отдельными таблицами Библиотекаря и Студента. Это одна и та же таблица. Кроме того, создавая отдельную таблицу студент вы запрещаете брать книги Преподавателям и людям, которые вообще не имеют отношения к вашему вузу.

Сначала я думал, что вам элементарно смелости не хватает их объединить в одну,
но потом я понял, что вы элементарно "обрезали себе крылья" использованием этого визуального инструмента, который не позволяет вам в одной таблице Операции создать два разные поля userIdStudent, userIdManager, которые ссылаются на одно и то же поле userId в другой таблице

Ну что про это можно сказать?
Вы сами себе злой буратино...

PS. Это ещё раз доказывает преимущество прототипирования живым кодом вместо всяких заумных визуальных конструкторов...

2) В таблице Операции поле называется не Выдача/Сдача, а Тип операции или Статус и не text а char(4)
3) В таблице Операции нет поля дата операции, там много дат: cdate, bdate, edate

PS. если вы работаете на PHP, то тип поля дата лучше делать int, чтобы проще было работать с юниксовыми таймстемпами

ABariyЧто посоветуете с корзиной книг по типу человек приходит и берет несколько книг, чтоб они как-то были объединены, кроме как костылей со стороны клиента ничего в голову не лезет.

1) Если следовать классическим канонам, то создаете дополнительное группировочное поле cartId и прописываете туда номер, взятый из глобального счетчика

2) Если следовать ремесленной смелкалке, которая формируется в результате многолетнего практического кодописания, то легко увидеть, что функцию группировочного признака играет пара (номер студента, дата начала операции)

номер студента играет общую группировочную функцию
а дата начала операции играет как бы сессионную группировочную функцию

система может дать сбой лишь в том, случае, если в течение одной даты может быть несколько выдач на одно лицо, то есть несколько "сессий" (сессия в данном случае - это айтишный термин, а не сессия как период экзаменов в вузе)

но насколько мне известно в библиотеках, если например, я утром взял 3 книги, а вечером ещё одну, то мне эту четвертую запишут к тем трем, а не будут создавать отдельную вторую выдачу за сегодня, потому что сроки все равно считаются в полных днях, без учета времени

Итого:
1) сожмите систему до трех таблиц: книга, пользователь, операция
2) введите поле Статус во пользователей (студент, библиотекарь, препод, прочий) и в операции (выдана, продлена, просрочена, возвращена)
3) переходите от визуальных поделок к реальному кодированию

miksoftLumixКроме того, создавая отдельную таблицу студент вы запрещаете брать книги Преподавателям и людям, которые вообще не имеют отношения к вашему вузу.Вот поэтому и говорилось выше про изучение предметной области.

Существуют классические уравнения.
x + 3 = 1
ответ: x = -2

А существуют уравнения с параметром.
x + a = 1
ответ: x = 1 - a

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

В вашей работе ответ всегда выглядит как x = 5
А в нашей работе ответы чаще всего выглядят вот так x = pow(c) - sqrt (a / b)

Проще говоря, мы в своей компании изначально считаем всех заказчиков как бы обкуренными и изначально готовимся к тому, что завтра может быть объявлен "полет на Марс".

То решение, которое я предложил, это решение на основе моей интуиции, которое покрывает туеву кучу возможных ТЗ.
И поэтому в моем решении на основе трех таблиц и статусных полей знание предметной области в данном случае не требуется вообще.


miksoftВ том институте, где я учился, посторонние люди не могли взять книгу. Да и преподаватели брали книги как-то иначе, потому как я ни разу в библиотеке их не видел.

В решении на трех таблицах - это неважно.
Потому что эта и другие варианты логики свободно покрываются этой конфигурацией базы.
Мы просто привыкли, что с момента начала проекта до момента его сдачи, ТЗ может поменяться 5 раз на 100%.
Поэтому мы уже физически перестали мыслить о какой-то предметной области и научились создавать максимально абстрактные архитектуры.

Например, вы даже представить себе не можете какое огромное множество прикладных задач можно замутить на основе всего этих трех таблиц: товар, юзер, операции.
У нас уже более 40 абсолютно разных программных решения для полностью разных отраслей сделано просто на этой троице.

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

Нет, в этом смысла нет никакого, потому что тогда на клиентском уровне придется вводить отдельный класс, а я из опыта знаю, что это просто глупость, потому что единственное чем они отличаются - это статусным полем.

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

miksoftЕсли задача не учебная, а реальная боевая (в чем я сильно сомневаюсь), то еще может понадобиться интеграция с другими учетными системами вуза, в частности, синхронизация списков студентов/сотрудников и т.п.

В любом случае синхронизация производится через некий синхронизатор, который является клиентским кодом, а клиентский код уж разберется что с чем синхронизировать.

miksoftLumixcdate, bdate, edateЭто что за слова такие?

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

cdate - create date
bdate - begin date
edate - end date
udate - update date

miksoftСистема настолько простая, что сменить структуру таблиц невидимо для пользователей никакой проблемы не составляет.

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

Кстати, то же самое касается таблицы товары.
В ней тоже есть смысл добавить поле статуса.
Зачем?
Да, потому что библиотека может начать выдавать диски.
Или грампластинки.
Или карты.
Или что-то ещё.
По вашей логике на каждую такую товарную группу придется создавать отдельную таблицу.
А зачем, если можно просто ограничиться идентификатором статуса?
При этом мы же понимаем, что состав полей у DVD-диска и у книги сильно различается.
Тем не менее, с опытом приходит понимание, что это одна сущность.

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