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) базы (которые вернут ошибку сразу, а не неправильные данные потом)
стройные нозьки
острый Ум..


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