Що таке Postgres? База даних, на якій працює багато застосунків, простими словами

Postgres (офіційно PostgreSQL) — це безкоштовна реляційна база даних з відкритим кодом: програма, яка зберігає дані застосунку в таблицях із рядками та стовпцями, пов'язує ці таблиці між собою і відповідає на запитання про них мовою SQL. Він відомий надійністю, суворістю щодо збереження коректних даних і гнучкістю — від списку реєстрацій до записів великої компанії. Багато вебзастосунків і сервісів, які їх розміщують, побудовано на ньому.

Чому це важливо, коли ви створюєте з ШІ

Коли конструктор застосунків на ШІ додає до вашого проєкту «базу даних», є добрий шанс, що це Postgres. Вам не обов'язково писати SQL, щоб ним користуватися, але трохи розуміння дуже допомагає:

• Ви можете описати дані у формі, яка потрібна базі. «Клієнти мають багато замовлень; кожне замовлення має багато позицій» безпосередньо перекладається на таблиці.
• Ви можете попросити потрібні захисти. Postgres може сам відхиляти погані дані — дубльований email, замовлення для неіснуючого клієнта — якщо ШІ налаштує правила.
• Ви можете перевірити, що зробив ШІ. Назви таблиць, стовпці та зв'язки легко перевірити в переглядачі таблиць, навіть якщо ви ніколи не торкаєтеся коду.

Повсякденна аналогія: дуже сувора канцелярія

Уявіть канцелярію з шафою для кожного виду речей — одна для клієнтів, одна для замовлень, одна для товарів. Кожна картка в шухляді має однакові друковані рубрики для заповнення. Кожна картка має унікальний номер, і картка замовлення не повторює деталі клієнта; вона просто каже «клієнт №214», вказуючи на шухляду клієнтів.

Клерк суворий. Він не прийме замовлення, що вказує на неіснуючого клієнта. Він не прийме картку з порожньою обов'язковою рубрикою. А якщо ви попросите перенести гроші з картки одного рахунку на картку іншого, він зробить або обидві частини, або жодної — ніколи лише одну.

Цей клерк — це Postgres. Шухляди — це таблиці, друковані рубрики — стовпці, кожна картка — рядок, а посилання «клієнт №214» — це зовнішній ключ.

Що Postgres робить добре

Postgres почався як дослідницький проєкт в Каліфорнійському університеті в Берклі у 1980-х роках і з 1990-х розвивається у відкритому режимі глобальною спільнотою. Ця довга історія — причина, чому він часто є типовим вибором: він добре задокументований, широко підтримується, і кожен великий хмарний провайдер пропонує його керовану версію.

Робочий приклад: перетворення електронної таблиці на таблиці

Скажімо, у вас невеликий бізнес кейтерингу, і ви ведете весь облік в одній таблиці: кожен рядок — це подія з іменем клієнта, телефоном, email, датою, позиціями меню і ціною.

Проблеми з'являються швидко. Той самий клієнт з'являється в шести рядках з двома різними номерами телефонів. Позиції меню записані в одну клітинку як «канапе x40, салат x2», тож ви не можете порахувати, скільки канапе зробили цього місяця.

У Postgres та сама інформація стає чотирма таблицями:

Тепер телефон клієнта зберігається в одному місці. «Скільки канапе ми зробили у березні?» — це один SQL-запит. А коли ви записуєте нову подію з її позиціями, транзакція гарантує, що ніколи не буде події з половиною збережених позицій.

Цей крок люди часто пропускають, коли просять ШІ «зробити застосунок з моєї таблиці». Посібник як перетворити електронну таблицю на застосунок розповідає більше.

Ключові терміни

• Таблиця, рядок, стовпець: вид речі, один її екземпляр, одна інформація про нього.
• Первинний ключ: унікальний ідентифікатор кожного рядка, зазвичай id.
• Зовнішній ключ: стовпець, що вказує на рядок в іншій таблиці, як-от client_id.
• Схема: опис усіх ваших таблиць і стовпців.
• Міграція: збережена, повторювана зміна схеми, наприклад «додати стовпець venue до events».
• Запит: запитання або інструкція, написана мовою SQL.
• Рядок підключення (connection string): адреса й пароль, за якими ваш бекенд звертається до бази. Це секрет — див. змінні середовища та секрети.
• Керований Postgres: сервіс, який запускає, резервно копіює й оновлює Postgres за вас.

Для повсякденних операцій, які кожен застосунок виконує над цими таблицями — створення, читання, оновлення, видалення, — див. що означає CRUD.

Поширені помилки та хибні уявлення

• Одна величезна таблиця. Копіювання стовпців таблиці один до одного веде до тих самих проблем з дублюванням. Виносьте те, що повторюється, у окремі таблиці.
• Зберігання списків в одному текстовому полі. «канапе x40, салат x2» в одному стовпці не можна коректно порахувати чи знайти. Використовуйте таблицю-зв'язку.
• Відсутність обмежень. Без правил «email має бути унікальним» або «кожна подія потребує клієнта» погані дані проникають непомітно і виринають через місяці.
• Ручні зміни бази в продакшні. Просіть зміни схеми як міграції, щоб зміна фіксувалася і могла бути повторена.
• Дозвіл браузеру звертатися до бази напряму. Фронтенд має йти через ваш бекенд, який перевіряє дозволи. Пароль до бази ніколи не належить до коду сторінки.
• «Postgres лише для великих компаній». Він так само добре працює для списку очікування на 50 рядків, і вам не доведеться з нього переходити, коли ви зростаєте.
• Припущення, що база даних — це резервна копія. Вона зберігає дані; вона не захищає автоматично від їх видалення. Перевірте, які резервні копії надає ваш хостинг.

Що попросити у вашого конструктора ШІ

• «Зберігай [речі] в базі даних. Таблиці: … з такими полями: … Пов'язуй кожне [замовлення] з [клієнтом].»
• «Зроби email унікальним для клієнтів. Зроби ці поля обов'язковими. Не дозволяй замовлення без клієнта.»
• «Використовуй міграції для кожної зміни схеми.»
• «Додай індекси для пошуків, які ми робимо найчастіше: замовлення за клієнтом і за датою.»
• «Увесь доступ до бази йде через сервер. Тримай рядок підключення у змінних середовища.»

Якщо ви взагалі новачок у ідеї бази даних, почніть із що таке база даних, а потім поверніться сюди. Повний стек застосунку показує, де база даних розташована поруч із фронтендом і бекендом.

Postgres у Mythex

Mythex надає кожному проєкту, якому вона потрібна, власну виділену базу Postgres. Налаштовувати її не треба: попросіть у чаті («зберігай email-адреси списку очікування в базі даних») або використайте команду /database, і Mythex підключить її, передасть параметри підключення вашому застосунку і може створити таблиці за вас. База опублікованого застосунку засинає після п'яти хвилин бездіяльності і прокидається з наступним запитом, а плата стягується лише за час, коли вона справді працювала, з того самого балансу кредитів, що й для створення. Деталі — в документації про базу даних, а шаблони панелей — гарне місце, щоб побачити застосунки з даними.

Запитання