Евгений Вольф

Но при попытке создать таблицы в редакторе SQL-запросов возникает ошибка синтаксиса на первом же поле таблицы. Проблема в Adminer или PostgreSQL ?

Наиболее вероятно, что проблема в SQL-коде, который Вы пытаетесь запустить/выполнить.

Посоветуйте нормальный редактор для PostgreSQL (без разницы уже под Винду или Линукс).

1. Navicat
2. EMS
3. SQL Maestro
4. PGAdmin-IV и PGAdmin III LTS от BigSQL
5. И другие, например эти или вот эти и т.д.

P.S. Из всего этого изобилия, лично мне понравились: PGAdmin, Navicat и поделка от EMS.

С учётом того, что по Postgres'у я уже не первый год возвращаюсь к чтению его документации - думаю, что "самоучителя" вменяемого, вряд ли найти удастся. Или это будет книга просто феерического объёма.

По MySQL - в своё время мне понравилась книга, автор (или соавтор) которой является некто "Кузнецов". Неплохая довольно книга была, на мой взгляд. Но, тут стоит сделать поправку - что это книга скорее про SQL-возможности базы, нежели про её глубокий анализ, тонкую настройку и т.д.

Общая теория реляционных БД - на эту тему, я думаю, Вы без проблем книги найдете.

Телефония - вообще плохо знаком с темой и особо не интересовался, пропущу.

Администрирование Linux - очень мало вероятно, что Вы найдете что-то полноценное. Во первых, по тому, что эта тема тянет за собой целую цепочку буквально всего, от сети и сетевых протоколов заканчивая механизмами ядра. Linux - это не только несколько штук/десятков/сотен/... команд в командной строке, это буквально всё, от установки софта и настройки веб-сервера до леший ещё знает чего. Вы легко найдете интересующий по какой-то конкретной теме, например, по работе с командной строкой, или по настройке того же веб-сервера, или по настройке iptables например. Но с учётом того, что по одному только iptables уже написана не одна книга (это же относится к командной строке, текстовому редактору vi и т.д., по всем этим темам есть как минимум одна книга посвященная только ей), представьте себе объём информации по теме "администрирование".

Хочу чтобы вывелся результат, в котором первый столбец - значения table1.items, второй столбец - значения table2.items делаю так:

Попробуйте так:

select table1.items, table2.items from table1 left join table2 on true

Помимо всего прочего, к запросы выше можно применять и group by и всё остальное. Но, если Вы внимательно почитаете про стандарт SQL, то поймете, что данные могут выводиться в совершенно хаотичном порядке (при отсутствии соотв. сортировки) и то, что данный запрос имеет некоторый оттенок маразма, так как данные хоть и выводятся так, как Вы сказали, но куда бы их в таком виде можно было применить, без отсутствия сопоставлений (с учётом того, что я озвучил выше) - придумать довольно таки сложно.

Не это часом ищите?

собрался делать "Система управления школьниками"

- всегда о такой мечтал!

Простите, не сдержался, далее по делу:
Я не могу знать Ваши личные предпочтения и манеры преподавания к которой Вы привыкли или считаете наиболее верными или предпочтительными, но в своей преподавательской практике, я не редко использовал метод "визуализации" происходящего. Довольно сложно объяснить человеку, который не работал с сетями, что такое 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 исключительно по каким-то идеологическим, а не техническим соображениям - подумайте ещё раз.