ABariy,

вы тут на сильных профессионалов нарвались и они, к сожалению, не дадут вам "скосить углы", то есть сделать по-быстрому и пойти пить пиво. )))

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

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

- - - - - - - - - - - -

1) группы книг и факультет таблицами не делать вообще, а ведите эти списки просто в файле. Если речь идет о php, то достаточно просто вести этот список в виде массива и хранить его через var_export()

массив - это комплект описание / метка, например




В таблице код группы сделайте char(8) и храните там буквенные идентификаторы.
То же самое с факультетами

- - - - - - - - - - - -

2) корзина книг и выдача сделайте одной таблицей и назовите её операции
3) выкиньте колонку возврат и добавьте колонку state char(4), а в которой бы будете хранить идентификатор типа операции




- - - - - - - - - - - -

4) объедините таблицу сотрудник и студент в одну и назовите её юзер
5) введите поле who char(4)




6) не бойтесь, что под какой-то статус какие-то поля будут лишние и пустые
например, для сотрудника есть поле "дата увольнения" и она лишняя для студентов, а для студентов есть поле "факультет" и оно лишнее для сотрудников, а для преподов есть поле "уч.степень" и оно лишнее для кого-то ещё. Ну и хрен с ним. Базе от этого пофиг, а вы на крайняк, если будет не лень просто будете скрывать эти поля в форме в зависимости от выбранного переключателя типа пользователя системы. Хотя если лень, то можно и не скрывать, потому что у сотрудника тоже может быть ученая степень и факультет, а у препода может быть дата увольнения.

- - - - - - - - - - - -

Итого всего 3 таблицы: товар, операции, юзеры

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

Удачи!

miksoftLumixЕсли речь идет о php, то достаточно просто вести этот список в виде массива и хранить его через var_export()Хардкодить данные???!!! Святотатство!!!

Если уж мы уже используем СУБД, то накой эти вспомогательные списки? (это риторический вопрос)

неее, var_export() это не хардкод
это хранение данных в файле
скорость доступа к этим данным по сравнению мускулом на порядки выше
а изменять эти списки можно как обычно через форму справочника
просто они хранятся не в базе, а в файле
подобное решение всегда выгодно, когда
1) элементов в списке меньше 666
2) они меняются редко
3) функционально эти списки носят носят меточный характер, то есть используются как метки
(классика жанра - это различные статусы, ну а на втором месте стоят различные группировочные признаки)

tanglirжесть какая
часть данных в БД, часть в файлах... ещё одна часть под фвмас, наверное?

ой, а фвмас - это шо це токке?


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

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

самая главная мотивация - это максимальное упрощение отладки, а значит и dramaticcaly снижение требования к минимальной квалификации кодера, способного сие софтзверьё обслуживать

MasterZivСкорость работы -- далеко не самый важный критерий при оценке качества ПО.

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

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-диска и у книги сильно различается.
Тем не менее, с опытом приходит понимание, что это одна сущность.

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