собрался делать "Система управления школьниками"
- всегда о такой мечтал!
Простите, не сдержался, далее по делу:
Я не могу знать Ваши личные предпочтения и манеры преподавания к которой Вы привыкли или считаете наиболее верными или предпочтительными, но в своей преподавательской практике, я не редко использовал метод "визуализации" происходящего. Довольно сложно объяснить человеку, который не работал с сетями, что такое IP4-пакет... но, когда рисуешь это визуально, качество восприятия значительно улучшается.
Собственно, к чему я это... Возьмите лист бумаги, или холст (paint, photoshop, etc.), или программу для рисования блок-схем, или программу для создания скетчей или что-то подобное и попробуйте отрисовать все таблицы/объекты БД и связи между ними. Так же, аналогичный функционал есть во многих программа для работы с БД (визуализация таблиц и их связей). Когда Вы будете визуально видеть и представлять объекты - гораздо проще воспринимать происходящее.
Пример из жизни - попробуйте объяснить человеку, что такое таблица реляционной БД... а если провести аналогию с листом из Excel - в 95% случаев, понимание приходит практически моментально.
Так же могу сказать, что выбор на начальном этапе PostgreSQL - не лучшая идея. PostgreSQL - очень классная БД, если Вы действительно понимаете зачем она Вам нужна и почему именно она. То есть, в тех случаях, когда Вам уже жмут "MySQL-штаны" и не хватает простора для действий и нескольких сотен лишних параметров, которые нужно подкрутить и поднастроить, а так же феерического количества параметров и возможностей самой БД - PostgreSQL будет оптимальным выбором, в ином же случае, Вы будете проклинать мир, разработчиков и всё сущее, постоянно сталкиваясь с некоторыми трудностями, которые иногда могут даже показаться глупостями (хотя, в 99% случаев это не так). Например, чего только стоит момент, что в PostgreSQL нет "табличных движков", или нельзя поменять местами ранее созданные колонки в таблице без полной перезаписи всей таблицы, или дюжина индексов (и какой выбрать?!), против куда более скудного количества в MySQL...
Мои студенты довольно часто сталкивались с подобными проблемами, по этому, мы пришли к такой практике - база проектируется и прототипируется на MySQL, меняется там до посинения, пока не будет выверен действительно нужный вектор развития БД, код обкатывается... а потом, проект легко и непринуждённо переезжает на PG, где впоследствии снабжается некоторыми плюшками и полезностями уровня PG (теми, который в MySQL-е нет).
Я рекомендую Вам, так же как и моим студентам - сначала спроектировать базу в MySQL, мы обычно делаем это в программе
HeidiSQL (бесплатная), всё очень наглядно и разноцветно. Обкатать Ваш код и логику работы БД, а потом уже, если сильно не терпится - переносить на Postgres.
Из личного опыта, могу сказать, что многие выбирают PostgreSQL, т.к. он(а) "круче". Это не совсем так, или, совсем не так... Из множества проектов, на PG мы поставили только один, там база данных исчислялась многими десятками и сотнями гигабайт, количество таблиц приближалось к тысяче, а кол-во записей в отдельно взятых таблицах - десятками миллионов. Но, даже сейчас я работаю в поддержке проекта, объёмы данных которого переваливают за 1Тб, и всё прекрасно живёт на MySQL. По этому, если Вы выбрали PG исключительно по каким-то идеологическим, а не техническим соображениям - подумайте ещё раз.
