Как отобразить модель базы данных в postgresql?
Как сделать скриншоты таблиц в postgresql? Сделала базу данных в postgesql. Теперь надо эти таблички «увидеть» не в виде кода типа «create table «, а в виде нормальных табличек, соединенных между собой, и заскриншотить их для последующего отчета по бд.
Отслеживать
3,324 1 1 золотой знак 10 10 серебряных знаков 21 21 бронзовый знак
задан 23 апр 2014 в 8:09
31 1 1 золотой знак 1 1 серебряный знак 3 3 бронзовых знака
select * from your_table в консоли постгреса или в Вашем любимом GUI для БД, а потом Alt+PrintScreen -> word -> Ctrl+V.
23 апр 2014 в 8:36
Мне интересно, а есть свежие реализации на данный вопрос? Не добавили никаких вариантов, чтобы в самом pgadmin можно было делать это?
18 сен 2020 в 20:00
2 ответа 2
Сортировка: Сброс на вариант по умолчанию
Данную возможность поддерживает большинство средств из данного списка https://wiki.postgresql.org/wiki/GUI_Database_Design_Tools
Рекомендую средства, которые отображают не просто связь между таблицами, а между атрибутами:
- DbVisualizer
- Valentina Studio
- pgModeller, но формат не очень красивый
Отслеживать
ответ дан 6 июн 2017 в 19:46
3,324 1 1 золотой знак 10 10 серебряных знаков 21 21 бронзовый знак
Сделала базу данных в postgesql. Теперь надо эти таблички «увидеть» не в виде кода типа «create table «, а в виде нормальных табличек, соединенных между собой, и заскриншотить их для последующего отчета по бд.
Для этих целей, есть средства моделирования в нотации UML, например Lucidchart (Flow Chart Maker & Online Diagram Software) . Вы можете «посмотреть» на таблицы из консоли выполнив команду \d
Если нужны именно данные в таблицах, то делайте запрос в таблицу
SELECT * FROM my_table;
Как в postgresql посмотреть схему данных
Кластер баз данных Postgres Pro содержит один или несколько именованных экземпляров баз. На уровне кластера создаются пользователи и группы, но данные могут относиться только к базам данных. При этом в рамках одного подключения к серверу можно обращаться к данным только одной базы данных, указанной при установлении соединения.
Примечание
Пользователи кластера не обязательно будут иметь доступ ко всем базам данных этого кластера. То, что пользователи создаются на уровне кластера, означает только, что в нём не может быть двух пользователей joe в разных базах данных, хотя система позволяет ограничить доступ joe только некоторыми базами данных.
База данных содержит одну или несколько именованных схем, которые в свою очередь содержат таблицы. Схемы также содержат именованные объекты других видов, включая типы данных, функции и операторы. Одно и то же имя объекта можно свободно использовать в разных схемах, например и schema1 , и myschema могут содержать таблицы с именем mytable . В отличие от баз данных, схемы не ограничивают доступ к данным: пользователь может обращаться к объектам в любой схеме текущей базы данных, если ему назначены соответствующие права.
Есть несколько возможных объяснений, для чего стоит применять схемы:
Чтобы одну базу данных могли использовать несколько пользователей, независимо друг от друга.
Чтобы объединить объекты базы данных в логические группы для облегчения управления ими.
Схемы в некоторым смысле подобны каталогам в операционной системе, но они не могут быть вложенными.
5.8.1. Создание схемы
Для создания схемы используется команда CREATE SCHEMA . При этом вы определяете имя схемы по своему выбору, например так:
CREATE SCHEMA myschema;
Чтобы создать объекты в схеме или обратиться к ним, указывайте полное имя, состоящее из имён схемы и объекта, разделённых точкой:
схема.таблица
Этот синтаксис работает везде, где ожидается имя таблицы, включая команды модификации таблицы и команды обработки данных, обсуждаемые в следующих главах. (Для краткости мы будем говорить только о таблицах, но всё это распространяется и на другие типы именованных объектов, например, типы и функции.)
Есть ещё более общий синтаксис
база_данных.схема.таблица
но в настоящее время он поддерживается только для формального соответствия стандарту SQL. Если вы указываете базу данных, это может быть только база данных, к которой вы подключены.
Таким образом, создать таблицу в новой схеме можно так:
CREATE TABLE myschema.mytable ( . );
Чтобы удалить пустую схему (не содержащую объектов), выполните:
DROP SCHEMA myschema;
Удалить схему со всеми содержащимися в ней объектами можно так:
DROP SCHEMA myschema CASCADE;
Стоящий за этим общий механизм описан в Разделе 5.13.
Часто бывает нужно создать схему, владельцем которой будет другой пользователь (это один из способов ограничения пользователей пространствами имён). Сделать это можно так:
CREATE SCHEMAимя_схемыAUTHORIZATIONимя_пользователя;
Вы даже можете опустить имя схемы, в этом случае именем схемы станет имя пользователя. Как это можно применять, описано в Подразделе 5.8.6.
Схемы с именами, начинающимися с pg_ , являются системными; пользователям не разрешено использовать такие имена.
5.8.2. Схема public
До этого мы создавали таблицы, не указывая никакие имена схем. По умолчанию такие таблицы (и другие объекты) автоматически помещаются в схему « public » . Она содержится во всех создаваемых базах данных. Таким образом, команда:
CREATE TABLE products ( . );
CREATE TABLE public.products ( . );
5.8.3. Путь поиска схемы
Везде писать полные имена утомительно, и часто всё равно лучше не привязывать приложения к конкретной схеме. Поэтому к таблицам обычно обращаются по неполному имени, состоящему просто из имени таблицы. Система определяет, какая именно таблица подразумевается, используя путь поиска, который представляет собой список просматриваемых схем. Подразумеваемой таблицей считается первая подходящая таблица, найденная в схемах пути. Если подходящая таблица не найдена, возникает ошибка, даже если таблица с таким именем есть в других схемах базы данных.
Возможность создавать одноимённые объекты в разных схемах усложняет написание запросов, которые должны всегда обращаться к конкретным объектам. Это также потенциально позволяет пользователям влиять на поведение запросов других пользователей, злонамеренно или случайно. Ввиду преобладания неполных имён в запросах и их использования внутри PostgreSQL , добавить схему в search_path — по сути значит доверять всем пользователям, имеющим право CREATE в этой схеме. Когда вы выполняете обычный запрос, злонамеренный пользователь может создать объекты в схеме, включённой в ваш путь поиска, и таким образом перехватывать управление и выполнять произвольные функции SQL как если бы их выполняли вы.
Первая схема в пути поиска называется текущей. Эта схема будет использоваться не только при поиске, но и при создании объектов — она будет включать таблицы, созданные командой CREATE TABLE без указания схемы.
Чтобы узнать текущий тип поиска, выполните следующую команду:
SHOW search_path;
В конфигурации по умолчанию она возвращает:
search_path -------------- "$user", public
Первый элемент ссылается на схему с именем текущего пользователя. Если такой схемы не существует, ссылка на неё игнорируется. Второй элемент ссылается на схему public, которую мы уже видели.
Первая существующая схема в пути поиска также считается схемой по умолчанию для новых объектов. Именно поэтому по умолчанию объекты создаются в схеме public. При указании неполной ссылки на объект в любом контексте (при модификации таблиц, изменении данных или в запросах) система просматривает путь поиска, пока не найдёт соответствующий объект. Таким образом, в конфигурации по умолчанию неполные имена могут относиться только к объектам в схеме public.
Чтобы добавить в путь нашу новую схему, мы выполняем:
SET search_path TO myschema,public;
(Мы опускаем компонент $user , так как здесь в нём нет необходимости.) Теперь мы можем обращаться к таблице без указания схемы:
DROP TABLE mytable;
И так как myschema — первый элемент в пути, новые объекты будут по умолчанию создаваться в этой схеме.
Мы можем также написать:
SET search_path TO myschema;
Тогда мы больше не сможем обращаться к схеме public, не написав полное имя объекта. Единственное, что отличает схему public от других, это то, что она существует по умолчанию, хотя её так же можно удалить.
В Разделе 9.25 вы узнаете, как ещё можно манипулировать путём поиска схем.
Как и для имён таблиц, путь поиска аналогично работает для имён типов данных, имён функций и имён операторов. Имена типов данных и функций можно записать в полном виде так же, как и имена таблиц. Если же вам нужно использовать в выражении полное имя оператора, для этого есть специальный способ — вы должны написать:
OPERATOR(схема.оператор)
Такая запись необходима для избежания синтаксической неоднозначности. Пример такого выражения:
SELECT 3 OPERATOR(pg_catalog.+) 4;
На практике пользователи часто полагаются на путь поиска, чтобы не приходилось писать такие замысловатые конструкции.
5.8.4. Схемы и права
По умолчанию пользователь не может обращаться к объектам в чужих схемах. Чтобы изменить это, владелец схемы должен дать пользователю право USAGE для данной схемы. Чтобы пользователи могли использовать объекты схемы, может понадобиться назначить дополнительные права на уровне объектов.
Пользователю также можно разрешить создавать объекты в схеме, не принадлежащей ему. Для этого ему нужно дать право CREATE в требуемой схеме. Заметьте, что по умолчанию все имеют права CREATE и USAGE в схеме public . Благодаря этому все пользователи могут подключаться к заданной базе данных и создавать объекты в её схеме public . Некоторые шаблоны использования требуют запретить это:
REVOKE CREATE ON SCHEMA public FROM PUBLIC;
(Первое слово « public » обозначает схему, а второе означает « каждый пользователь » . В первом случае это идентификатор, а во втором — ключевое слово, поэтому они написаны в разном регистре; вспомните указания из Подраздела 4.1.1.)
5.8.5. Схема системного каталога
В дополнение к схеме public и схемам, создаваемым пользователями, любая база данных содержит схему pg_catalog , в которой находятся системные таблицы и все встроенные типы данных, функции и операторы. pg_catalog фактически всегда является частью пути поиска. Если даже эта схема не добавлена в путь явно, она неявно просматривается до всех схем, указанных в пути. Так обеспечивается доступность встроенных имён при любых условиях. Однако вы можете явным образом поместить pg_catalog в конец пути поиска, если вам нужно, чтобы пользовательские имена переопределяли встроенные.
Так как имена системных таблиц начинаются с pg_ , такие имена лучше не использовать во избежание конфликта имён, возможного при появлении в будущем системной таблицы с тем же именем, что и ваша. (С путём поиска по умолчанию неполная ссылка будет воспринята как обращение к системной таблице.) Системные таблицы будут и дальше содержать в имени приставку pg_ , так что они не будут конфликтовать с неполными именами пользовательских таблиц, если пользователи со своей стороны не будут использовать приставку pg_ .
5.8.6. Шаблоны использования
Схемам можно найти множество применений. Хотя есть несколько шаблонов использования, легко поддерживаемых стандартной конфигурацией, только один из них достаточно безопасен, когда одни пользователи базы данных не доверяют другим:
Ограничить обычных пользователей личными схемами. Для реализации этого подхода выполните REVOKE CREATE ON SCHEMA public FROM PUBLIC и создайте для каждого пользователя схему с его именем. Если затрагиваемые пользователи подключались к базе ранее, проведите аудит схемы на предмет наличия таких же имён, как в схеме pg_catalog . Вспомните, что путь поиска по умолчанию начинается со значения $user , которое разрешается в имя пользователя. Таким образом, если у всех пользователей будет отдельная схема, они по умолчанию будут обращаться к собственным схемам.
Удалить схему public из пути поиска по умолчанию для каждого пользователя с помощью команды ALTER ROLE пользователь SET search_path = «$user» . Все сохранят возможность создавать объекты в общедоступной схеме, но обращаться к ним будут только по полным именам. Хотя обращение к таблицам по полным именам вполне безопасно, вызовы функций в схеме public будут небезопасными или ненадёжными. Кроме того, пользователь, имеющий право CREATEROLE , может отменить это назначение и выполнять произвольные запросы от имени пользователей, полагающихся на этот путь. Если вы создаёте функции или расширения в схеме public или даёте пользователям право CREATEROLE , но не хотите, чтобы они стали практически суперпользователями, вам нужно использовать первый шаблон.
Удалить схему public из пути поиска search_path в postgresql.conf . Это будет иметь такое же влияние на пользователей, что и предыдущий шаблон. В дополнение к его особенностям относительно функций и права CREATEROLE , данный шаблон подразумевает также доверие к владельцам базам данных, как к имеющим право CREATEROLE . Если вы создаёте функции или расширения в схеме public, даёте пользователям права CREATEROLE , CREATEDB или делаете их владельцами отдельных баз данных, но не хотите, чтобы они стали практически суперпользователями, вам нужно использовать первый шаблон.
При любом подходе, устанавливая совместно используемые приложения (таблицы, которые нужны всем, дополнительные функции сторонних разработчиков и т. д.), помещайте их в отдельные схемы. Не забудьте дать другим пользователям права для доступа к этим схемам. Тогда пользователи смогут обращаться к этим дополнительным объектам по полному имени или при желании добавят эти схемы в свои пути поиска.
5.8.7. Переносимость
Стандарт SQL не поддерживает обращение в одной схеме к разным объектам, принадлежащим разным пользователям. Более того, в ряде реализаций СУБД нельзя создавать схемы с именем, отличным от имени владельца. На практике, в СУБД, реализующих только базовую поддержку схем согласно стандарту, концепции пользователя и схемы очень близки. Таким образом, многие пользователи полагают, что полное имя на самом деле образуется как имя_пользователя . имя_таблицы . И именно так будет вести себя Postgres Pro , если вы создадите схемы для каждого пользователя.
В стандарте SQL нет и понятия схемы public . Для максимального соответствия стандарту использовать схему public не следует.
Конечно, есть СУБД, в которых вообще не реализованы схемы или пространства имён поддерживают (возможно, с ограничениями) обращения к другим базам данных. Если вам потребуется работать с этими системами, максимальной переносимости вы достигнете, вообще не используя схемы.
| Пред. | Наверх | След. |
| 5.7. Политики защиты строк | Начало | 5.9. Наследование |
Как получить информацию о структуре БД для документации
Из этой статьи вы узнаете, зачем нужно отслеживать метаданные в ИТ-проектах и какие существуют основные подходы к документированию баз данных, а также познакомитесь с примерами SQL запросов, которые помогут получить сведения о структуре и составе реляционной базы данных.
Это поможет любому участнику команды, а в первую очередь системному аналитику, решить такие задачи:
- Корректно сформулировать задачу на доработку системы в ситуации, когда её БД не описана
- Оценить актуальность имеющейся документации на БД
- Выполнить инвентаризацию информационных ресурсов
- Проводить мониторинг состояния БД на проекте
Время на чтение статьи: 14 минут
Оглавление
Какие метаданные полезно знать о своей БД?
При работе над любым ИТ-проектом полезно иметь возможность посмотреть на данные своих систем с высоты птичьего полёта.
Вот какая информация пригодится вам в первую очередь.
- Физическая структура данных: объекты БД (в первую очередь — таблицы и поля, их наименования, типы данных, допустимые диапазоны значений, ключи, а также — пользователи, индексы, представления и т. п.)
- Объём данных, частота их обновления, дата последнего обновления БД
- Модель данных (логическая, концептуальная) — ключевые атрибуты и сущности, связь между ними
- Смысл и значение данных, объяснение основных сущностей на языке бизнеса
- Распределение данных (количество пустых полей, кардинальность (количество уникальных и повторяющихся значений)
- Ответственный за данные — кто может пояснить смысл данных или помочь исправить найденные проблемы в них
Что такое словарь данных и зачем он нужен
Мы будем подразумевать под «словарем данных» (англ. — data dictionary) справочник или централизованное описание метаданных, дающее представление о структуре и содержании данных. У этого термина есть и другое значение, в рамках данной статьи не используемое: словарём данных называют технику моделирования, дополняющую требования при проектировании информационных систем, в культуре Systems Analysis and Design.
Мы все знаем, что в целостном и удобном для использования виде найти такую информацию по своему проекту аналитику бывает непросто. Структура таблиц базы данных попросту не описана в документации. Почему же так происходит?
Моделирование предметной области и проектирование баз данных
Воркшоп для системных аналитиков и не-разработчиков уровня джун или мидл, которые хотят спроектировать логическую модель базы данных и изучить основы нормализации баз данных. Особенно актуально для тех, кто еще не знаком с базами данных.
Традиционный подход для старта проектирования БД
Почему так редко задумываются о документировании БД?
- Это самая неинтересная для программистов часть
- На старте проекта БД создаётся по интуиции и видению разработчиков
- Для данных редко выделяется отдельный архитектор или просто ответственное лицо в команде
- По мере роста проекта требования к БД сложно выделить из множества требований на доработку
Вначале всё кажется очевидным, но по мере роста проекта оказывается, что единого описания данных и их структуры не существует, также как и носителя информации об этом среди участников команды. Иногда оказывается, что устройство БД уже усложнилось до такой степени, что приходится организовывать целую исследовательскую экспедицию для восстановления этой информации. В идеале нужно поддерживать актуальность информации о данных системы, и делать это можно разными способами.
Какие средства документирования можно применять для описания БД?
| Инструмент, тип документации | Какую информацию можно найти | Примеры и комментарии | Что почитать |
| Специальные платформы управления данными Data Management. | • Каталог данных (Data Catalog) — единый источник сведений о всех информационных активах организации. • Список полей и атрибутов • Метаданные — например, информацию о размере таблиц, дате последнего обновления • Информацию об ответственных лицах • Бизнес-глоссарий |
Дороги в применении, используются в крупных только в больших компаниях, актуальны для проектов создания DWH (централизованное персистентное хранение данных всего предприятия для аналитики). | Что такое каталог данных? Видео от DIS Group |
Как вы уже поняли, если перед вами стоит задача понять смысл и структуру данных вашей системы, то придётся обращаться к нескольким источникам. Рыться в документации полезно, но утомительно. Наверно, вам уже пришла в голову мысль, что лучший способ понять вашу базу данных «as is» будет заключаться в том, чтобы подключиться к ней и «пощупать её руками».
Источники информации о БД
Как можно получить информацию о данных, используемых в системе?
| Способ | Описание | Пример |
| Использовать специализированные инструменты, обеспечивающие возможность просмотра объектов БД. | Способ позволит визуально быстро понять, какие объекты есть в вашей базе данных. Можное осмотреть список таблиц и о каждой из них узнать что-то из контекстного меню или другой части внутри GUI используемого средства. Однако, получать, хранить и передавать информацию в такой форме неудобно. | Документация к редактору объектов DBeaver |
| Вывести информацию об объектах БД с помощью соответствующих SQL запросов к служебным таблицам. | В РСУБД существуют служебные таблицы, которые содержат интересующие нас сведения об объектах базы данных. Вы можете строить несложные SQL запросы к служебным таблицам и системным каталогам БД (помимо таблиц со схемой, среди служебных таблиц обычно есть много интересного). | Использование схемы данных в SQL Server |
Не все из перечисленных способов могут быть доступны аналитику. Например, возможность просмотра полной схемы БД бывает ограничена только для администраторов, а построение запросов к служебным таблицам требует знания особенностей конкретной СУБД. В следующих частях статьи вы найдёте примеры таких запросов и сможете начать использовать их прямо сейчас.
Как получить информацию о БД
Как быстро получить словарь данных для популярных БД?
Несколько слов по данному вопросу от Александра Кротова.
Полагаю, многие системные и бизнес-аналитики сталкивались с задачей инвентаризации информационных ресурсов организации, то есть с работой по описанию имеющихся в наличии автоматизированных систем, баз данных, локальных АРМ-ов и других ИТ-объектов, играющих определённую роль в бизнес-процессах. Как правило, такие работы проводятся в целях анализа состояния и эффективности ИТ-инфраструктуры внутри компании или на стороне заказчика, либо на фазе обследования в проектах, связанных с доработкой существующих систем. Зачастую работа по документированию текущего состояния дел возлагается на системного аналитика или бизнес-аналитика. В этой статье мы не будем обсуждать всё, что может быть связано с подобной инвентаризацией, а остановимся на подходах к обследованию одного типа ИТ-ресурсов компании — её баз данных.
В идеале, конечно, такое обследование должно начинаться с изучения документации на используемые базы данных, но проблема в том, что далеко не всегда (а по моему опыту, так и почти никогда) такая документация существует. А если документация на БД существует, то крайне редко бывает достаточно полной и актуальной.
Что делать в такой ситуации? Первое, что пришло бы мне в голову, это провести для всех баз данных так называемый «реверс-инжиниринг» (reverse engineering). Можно было бы изучить имеющиеся данные и их структуру, взять могучее универсальное средство моделирования, построить ER-модели, сформировать текстовое описание и приступить к более глубокому анализу полученных материалов. Но здесь мы можем натолкнуться на ряд проблем: универсальные средства моделирования, способные работать с разными СУБД, стоят, как правило, дорого, и далеко не каждый работодатель будет готов потратить деньги на приобретение подобного программного продукта. А вероятность того, что в процессе инвентаризации информационных ресурсов придётся столкнуться с так называемым «зоопарком», то есть разбродом и шатанием в платформах, СУБД и их версиях, достаточно высока. Иначе и задача наведения порядка в информационном хозяйстве вообще вряд ли бы возникла.
И вот, в ситуации, когда «зоопарк» есть, а актуальной документации и подходящего инструмента для её создания нет, можно пойти по другому пути и попробовать сформировать необходимую для анализа документацию на основе так называемых «словарей данных» — служебных таблиц, в которых реляционная (и не только) СУБД хранит описание своих объектов — таблиц, полей, представлений, ключей, индексов и многого другого. В том или ином виде такие словари должны быть в любой СУБД, хотя структура их может сильно различаться. В общем, я решил посмотреть, как подобные словари устроены, взяв для примера несколько популярных СУБД: MySQL, PostgreSQL, Oracle, SQLite, MS Access. А задачу я себе поставил простую: для каждой СУБД написать SQL-запрос, который сформирует описание таблиц и полей выбранных баз данных. Только хотел бы предупредить, что для разных версий одной и той же СУБД запросы могут немного отличаться, но, думаю, это и так очевидно.
Словарь данных для MySQL
Начал я с MySQL. Здесь всё оказалось достаточно просто. Можно использовать стандартную схему под названием INFORMATION_SCHEMA (говорят, даже ANSI на неё свой стандарт оформила для разных СУБД). Схема содержит таблицы, в которых можно легко найти все необходимые метаданные. В нашем случае достаточно соединить таблицы TABLES (таблицы) и COLUMNS (поля) по именам схемы и таблицы, выбрать нужные атрибуты, присвоить понятные псевдонимы, задать условия выборки (например, по имени схемы и типу объектов, как на примере ниже). Получится примерно такой запрос:
Получим результат вот такого вида
(показано на фрагменте отчёта для учебной БД «Студенты»):
| Таблица | Комментарий к таблице | № п.п | Поле | Комментарий к полю | Тип | Ключ | NULL |
| EMPLOYEE | Сотрудники | 1 | ID | Идентификатор | int(11) | PK | NO |
| EMPLOYEE | Сотрудники | 2 | LAST_NAME | Фамилия | varchar(45) | NO | |
| EMPLOYEE | Сотрудники | 3 | FIRST_NAME | Имя | varchar(45) | NO | |
| EMPLOYEE | Сотрудники | 4 | MIDDLE_NAME | Отчество | varchar(45) | YES | |
| EMPLOYEE | Сотрудники | 5 | BIRTHDAY | День рождения | date | YES | |
| GRADE | Оценки | 1 | ID | Идентификатор | int(11) | PK | NO |
| GRADE | Оценки | 2 | STUDENT_ID | ИД студента в группе | int(11) | YES | |
| GRADE | Оценки | 3 | MODULE_NUM | Номер модуля | int(11) | YES | |
| GRADE | Оценки | 4 | GRADE | Оценка | int(11) | YES | |
| GROUP_ST | Учебные группы | 1 | ID | Идентификатор | int(11) | PK | NO |
| GROUP_ST | Учебные группы | 2 | GROUP_CODE | Код группы | varchar(45) | YES | |
| GROUP_ST | Учебные группы | 3 | TEACHER_ID | ИД сотрудника-преподавателя | int(11) | YES | |
| GROUP_ST | Учебные группы | 4 | CURATOR_ID | ИД сотрудника-куратора | int(11) | YES | |
| STUDENT | Студенты | 1 | ID | Идентификатор | int(11) | PK | NO |
| STUDENT | Студенты | 2 | LAST_NAME | Фамилия | varchar(45) | NO | |
| STUDENT | Студенты | 3 | FIRST_NAME | Имя | varchar(45) | NO | |
| STUDENT | Студенты | 4 | MIDDLE_NAME | Отчество | varchar(45) | YES | |
| STUDENT | Студенты | 5 | BIRTHDAY | День рождения | date | YES |
Единственное, надо не забывать, что запрос вернёт только те объекты БД, на просмотр которых у текущего пользователя есть привилегии. И ещё я бы обратил внимание на атрибут ORDINAL_POSITION, который был использован в составе оператора ORDER BY после TABLE_NAME (имя таблицы). Атрибут предназначен для хранения порядка полей, заданного в DDL-скрипте при создании таблицы (оператор CREATE TABLE) или установленного разработчиком позже (кстати, возможность изменять порядок полей после создания таблицы реализована далеко не во всех СУБД, MySQL здесь обогнал многих). Но зачем хранить исходный порядок полей, если теория реляционных баз данных утверждает, что порядок полей в таблице не несёт никакой смысловой нагрузки? Полагаю, эта возможность реализована исключительно для удобства пользователя. Разработчик, создавая таблицу, задаёт порядок полей не просто так, а на основе определённой бизнес-логики, и вправе ожидать, что выполнив запрос типа SELECT * FROM … без явно указанного порядка полей, или создав отчёт на основе словаря данных, как мы это сделали выше, он получит поля в порядке, соответствующем заложенной логике, а не как попало. Аналогичные по сути атрибуты с порядковым номером поля в таблице, есть и в других СУБД, что мы увидим ниже.
Как посмотреть структуру таблицы sql
Можно посмотреть колонки таблицы и тип данных через, например, pgAdmin .
Также через psql можно выполнить запрос вида:
SELECT column_name, column_default, data_type FROM INFORMATION_SCHEMA.COLUMNS WHERE table_name = 'super_table'; Этот запрос вернёт название колонки, её значение по умолчанию, а также тип данных.