GeronemoВсем привет.

Потихоньку осваиваю SQL. Владею им на самом начальном уровне, хотелось бы довести хотя бы до начально-среднего. Читаю книги.
И решил создать простенькую БД, в которую запихаю какое-то количество данных и буду экспериментировать с нею в процесс чтения той или иной книги.
База данных описывает библиотеку, в которой присутствует M книг N авторов (M>=N). Также есть читатели и каждый из них может взять на чтение несколько книг.
При этом я думаю на первое время сделать упрощение, что каждой книги очень много и несколько человек могут взять по экземпляру (иначе мне придется вводит поле, взята ли книга или хранится в библиотеке, или же поле, в котором хранится количество определенных книг в библиотеке, например Книга1 - 1 штука, Книга 2 - 3 штуки)

БД выглядит вот так. Зацените плиз, все ли верно с т. з. грамотного проектирования БД. Еще вопрос по поводу моих упрощений, может не стоит их делать, а сразу сделать самый трудный вариант (т. е. в таблицу Book ввести поле 'количество')?

create database Library;
use Library;

create Table Autors (id int(10) auto_increment, firstName varchar(10), lastName varchar(10), primary key (id));

create Table Book (id int(10) auto_increment, authorId int(10), bookName varchar(100), primary key (id), foreign key (authorId) references Autors(id));

create Table Readers (id int(10) auto_increment, firstName varchar(10), lastName varchar(10), primary key (id));

create table TakenBooks (id int(10) auto_increment, bookId int(10), readerId int(10), foreign key (bookId) references Book (id), foreign key (readerId) references readers (id), primary key (id)); КАЖДАЯ книга (ея экземпляр) - имеет свой идентификатор
типа - ИнвНомер (..на 17-й странице..)



простенько

мэйн тблка - Визит (когда- кто и тд... )

под неё
дитэйл тблка (ПК-ФК)
в которой -
- экземпляр'ы'..
чо взял Читатель....

соответственно - разнообразные Статусы
типа - Должник, Утеря..
и тп..


в тблке TakenBooks - не хватает Дат

Geronemo....Ладно, пусть будет 1 таблица, где будут и писатели и читатели....
ну,
пришёл к Вам живой Классик
и взял чо-нить 'из своего'

а потом
вернул...

о
засада..)))

SERG12571001 КАЖДАЯ книга (ея экземпляр) - имеет свой идентификатор
типа - ИнвНомер (..на 17-й странице..)А вот это совершенно не факт. И как раз для таких моментов нужен заказчик.
2 Geronemo
Давайте я вам помогу
Итак имеем библиотеку - книги, авторы, читатели

Действия (запросы)
библиотекарь добавляет книгу (или экземпляры) в библиотеку
читатель ищет книгу
читатель берет книгу
читатель возвращает книгу
читатель смотрит наличие книги в библиотеке
читатель смотрит кому выдавали экземпляры книги.
библиотекарь списывает экземпляр книги.

Geronemo Кстати, появился вопрос по синтаксису.Идите в форум для вашей СУБД
во-во
это - движняк
где надо - он - во времени...
автор...Итак имеем библиотеку - книги, авторы, читатели...прально,
а так же примитивно
- красиваыеБиблиотекарши,помещение, стеллаж, полка...и тд


SERG1257 ..А вот это совершенно не факт. И как раз для таких моментов нужен заказчик...

:))
пылится себе где-то некий экземпляр
и даже не знает,
что
есть какой-то там - Заказчик
и не только...
..(((

Geronemo ...

Попробую тоже придумать какой-то список действий
1. В библиотеку пришел новый человек
2. В библиотеку поступила новая книга (n-экземпляров, возможно она уже есть в кол-ве m-экземпляров)

сначала как можно правильнее
построить БД

а уж потом
пусть
3. Читатель ищет книгу (по разным параметрам, по автору, какое-то конкретное произведение и т. д.)
4. Читатель берет книгу почитать
5. Читатель возвращает книгу.
6. Библиотекарь смотрит кому выдавали экземпляры книги (каким читателям, сколько всего раз и т. д.)
7. Библиотекарь смотрит как часто берут книги того или иного автора (тут тоже можно посмотреть сколько все в сумме брали и сколько каждый читатель в отдельности).
8. Библиотекарь списывает экземпляр книги (если был 1, то будет 0, запись о книге не удаляем).
Вы
не спеша
определитесь
- в сутях
- в процессах
...


порисуйте их ...



правильно будет
периодически поспать (перекурить)
во сне еще много-чо приснится...))

SERG1257Geronemo Попробую тоже придумать какой-то список действийВот и пишите SQL для каждого действия. Потом можно напихать данных побольше и задумыватся об индексировании.
Дальше пусть заказчик изменит свою точку зрения? согласно 1001 и потребует учитывать книги поштучно. Переделайте базу и перепишите SQL.

DarkMasterSERG1257.
Вот недостатки навскидку
1 увеличили вероятность ошибки (оптимизатор не заругается на левую таблицу)
2 убрали возможность дать разные права
3 блокировка таблицы (типа индексы перестоить) блокирует обе таблицы
4 полный скан будет читать лишние страницы


1) Давайте сначала доберемся до SQL запросов, ага? Тогда и будем учить оптимизатор.
2) О каких разных права вы говорите?
3) Стоп. Я из 2-х таблиц сделал одну. Где вторая? Или вы сами с собой спорите? И перестройка индекса - оно конечно да, операция ежечасная.
4) А поподробнее можно? При правильных запросах и индексах и полный скан?

P.S. А можно все-таки ответить на вопрос - вот есть два человека - Азимов и Брэдбери - оба они авторы - могут ли они читать произведения друг друга?

P.P.S. Интересно, как с таким подходом вы будете каталог библиотеки с иерархией жанров строить ;)

Mr.Fontaine1001, если внимательно прочитать сообщения, то в выделенной Вами цитате разговор далёк от библиотеки автора темы. Они там реальный случай с объединением кучи таблиц рассматривали. Так что обсуждение перестройки индексов там вполне уместносогласен

но ТС-то клюет 'навсё'
мой посыл был именно в этом смысле

GeronemoMasterZivНу и что?
На учебных проектах и нужно учиться анализировать предметную область.
А именно этого автор топика и не сделал сходу.
Очевидная мысль о множестве авторов у книги ему в голову не пришла, хотя в IT книги большей частью написаны именно в соавторстве.

Я тут недавно в рамках процесса повторения/вспоминания синтаксиса java делал небольшой проект. Начал с того, что консольное приложение посылает данные Сервлету, тот должен запуститься и вернуть какой-то ответ. Далее я стал записывать запросы в файл. Потом у меня появились запросы разных типов, для которых нужен свой обработчик. Потом я стал сохранять данные в БД. Потом я перестроил БД так, чтобы разбить запросы от клиентов на 3 стадии - запрос получен и сохранен, запрос (т. е. пакет запросов данного типа) передан на обработку, запрос обработан и отправлен в архив. Для этого пришлось вводить несколько потоков, а также решать вопрос целостности данных. Ну и потом я переделал проект под maven и JPA.
И это при том, что с java я когда-то работал достаточно много. 1-я половина ТЗ была мне дана знакомым, а потом я уже сам развернулся.

Здесь же с SQL я знаком на уровне select ... from .... where, create, update ... where.
Т. ч. я решил начать с малого, чтобы просто хоть как-то работало. В процессе я все равно все переделаю и надобавляю кучу разных вариантов. Сейчас у меня голова от них пухнет. Может быть несколько авторов, могут быть однофамильцы, книги могут быть не возвращены, причем вероятно есть какие-то злостные должники и т. д. Также возможны разные библиотекари, как внимательные и ответственные, так и нет.

На данный момент БД, я немного подумав, решил обратно разделить писателей и читателей. В конце концов, если писатель придет в библиотеку что-нибудь взять, мы можем записать его как читателя. Ведь в жизни так и происходит. Я написал книгу, она лежит в библиотеке. Я прихожу туда и мне говорят, вы тут в первый раз ? Я говорю Да и на меня заводят карточку или запись в БД, если библиотека современная. Никто же меня не спрашивает, а не автор ли я какой-либо книги, давайте вашу карточку пометим особым цветом, а я ведь могу еще и соврать или писать под псевдонимом.
В общем пусть будут пока и Читатели и Писатели. Более того, я подумываю у писателей объединить firstName и lastName в fullname.
Иначе как мне именовать Эрик Мария Ремарка и Френсис Скотт Фитцжеральда. Это реально проблема, с которой я уже столкнулся.
Хотя можно оставить firstName и lastName, а fullname по дефолту firstName + lastName и при созданиии Писателя пользоваться не insert into, а процедурой addWriter (firstName, lastName, fullName (maybe null));просто многабукаф бз очков - не осилю..


ну
еще красиваяБбиблиотекарша может ббыть
и читателем и писателем
и библиотекарш0й



(Ц)...На учебных проектах и нужно учиться анализировать предметную область..





ТС - шахматист..)
типа - затеял п0ртейку
кот-я точно доведет его до - ченибудь реального

SERG1257Ну полагаю можно подвести некоторые итоги для Geronemo

Любая база суть модель реальной действительности. Модель может быть адекватной и не очень (одна моделька машины имеет только колеса и ездит, другая моделька имеет колеса, открывающиеся дверцы, но не ездит). В том и планида проектировщика, чтобы выбрать нужную модель, причем такую которая переживет смену мнений заказчика. Если проектировщик выбрал верно, то этого никто не заметит, а вот если ошибся, то пеняют все (как можно заблудится в трех соснах, это же очевидно). Это задача проектировщика (точнее менеджера проекта) решать когда сказать - хватит углублятся, давайте уже сделаем пилотный проект

Одного правильного ответа (типа 2*2=4) не существует. Для того же наследования я знаю три разных реализации (с одной таблицей, двумя или тремя) , каждая со своими достоинствами и недостатками. И это задача проектировщика выбрать одну реализацию, котораю будет использовать достоинства и нивелировать недостатки и ответить за свой выбор (см выше).

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

Для ощущения полного цимеса, лучше проводить изменения на живой базе с данными (а лучше с большим количеством данных и жестким временем простоя). Только тогда разработчик поймет прелесть ограничений (constraint) базы (которые вернут ошибку сразу, а не неправильные данные потом)
стройные нозьки
острый Ум..


и, главное,
душа

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

Как-то так.