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Скорость работы -- далеко не самый важный критерий при оценке качества ПО.

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