SQL-дамп (.sql)
ISO/IEC СтандартСценарій SQL: це текстовий файл із командами бази даних, наприклад CREATE TABLE, INSERT і SELECT. Діалекти SQL різняться, тому перед запуском перевірте, чи підтримує цільова база даних синтаксис сценарію.
Конвертувати з SQLITE у SQL
Безкоштовний конвертер з SQLITE у SQL у браузері. Миттєво конвертуйте файли на своєму пристрої.
Аналіз та метадані
Операційні системи та аналізатори файлів ідентифікують файли SQL, перевіряючи початкову послідовність бінарних байтів:
Сигнатура заголовка на байтовому рівні (Magic Bytes)
Операційні системи та аналізатори файлів ідентифікують файли SQL, перевіряючи початкову послідовність бінарних байтів:
ШІСТНАДЦЯТКОВА СИГНАТУРА (ЗСУВ 0):
Фіксованої сигнатури немаєПОДАННЯ В ASCII: Фіксованої сигнатури немає
Стандартизація: ISO/IEC 9075:2023 / ANSI SQL Standard
Технічні характеристики
| Архітектура контейнера | Звичайний текстовий скрипт Unicode, що містить оператори мови визначення даних (DDL) та мови маніпулювання даними (DML) |
| Стиснення | Нестиснений звичайний текст (часто стискається як .sql.gz або .sql.zst) |
| Порядок байтів (Endianness) | Потік тексту UTF-8 / Unicode |
| Колірні простори | Не застосовується (Скрипт бази даних) |
| Канали та структура | Визначення реляційних схем (таблиці, подання, індекси, зовнішні ключі) та рядки даних INSERT |
| Максимальні розміри | Необмежена довжина тексту (підтримує багатотерабайтні дампи баз даних) |
| Прозорість | Відсутня |
| Потокове та прогресивне завантаження | Транзакційне потокове виконання операторів один за одним |
Технічна матриця порівняння: SQL проти конкурентів
| Технічний атрибут | SQL (Поточний) | CSV | JSON | SQLITE |
|---|---|---|---|---|
| Збереження схеми | Повна схема (таблиці, типи, зовнішні ключі) | Тільки назви стовпців заголовка | Самоописувана структура документа | Повний файл бінарної бази даних |
| Модель виконання | Виконуваний скрипт DDL/DML | Пасивні табличні дані | Пасивне дерево документів | Прямий запит бінарного B-дерева |
| Стандартизація | Стандарт ISO/IEC 9075 | RFC 4180 | RFC 8259 | Відкритий формат файлів SQLite |
| Взаємозв'язки даних | Повні обмеження зовнішніх ключів | Плоскі табличні (без зв'язків) | Вкладені об’єкти за принципом «батьківський: дочірній» | Повні реляційні обмеження |
Типові режими пошкодження та посібник з відновлення в шістнадцятковому форматі
Імпорт бази даних завершується з помилкою 'ERROR: syntax error at or near...'.
Першопричина: Несумісність діалектів SQL (наприклад, імпорт дампу MySQL зі зворотними лапками в PostgreSQL) або неекрановані одинарні лапки.
Відновлення: Перетворіть синтаксис SQL-діалекту та очистіть його за допомогою File2File.app Database Transpiler.
Аналіз безпеки та векторів атак на парсери
Виконання неперевірених скриптів SQL може спричинити катастрофічну SQL-ін'єкцію, довільний запис файлів або ескалацію адміністративних привілеїв.
Відомі вектори атак
- SQL-ін'єкція (SQLi), що виконує ненавмисні адміністративні команди (наприклад, DROP TABLE, GRANT ALL).
- Довільне читання/запис файлів сервера через 'COPY ... FROM PROGRAM' або 'LOAD DATA INFILE'.
- Відмова в обслуговуванні через рекурсивні вирази спільних таблиць без індексів (CTE).
Рекомендації щодо захисту: Ніколи не виконуйте недовірені скрипти SQL безпосередньо на серверах баз даних у виробничому середовищі; перевіряйте та очищуйте запити в ізольованих пісочницях.
Історичне походження та віхи
Основні переваги
- Сценарії SQL можуть визначати таблиці, додавати рядки й виконувати запити до реляційних баз даних. Синтаксис типів даних, стовпців identity і функцій дат відрізняється в SQLite, MySQL, PostgreSQL і SQL Server.
- Повне відтворення реляційної структури: відтворює таблиці, первинні ключі, зовнішні ключі, обмеження та індекси разом із даними.
- Транзакційне виконання: оператори можуть виконуватися всередині транзакцій (BEGIN...COMMIT) для гарантування атомарного відновлення бази даних.
Технічні обмеження та недоліки
- Несумісність діалектів: тонкі відмінності в синтаксисі (наприклад, AUTO_INCREMENT проти SERIAL проти AUTOINCREMENT) вимагають адаптації для різних систем баз даних.
- Величезні накладні витрати на текст: прості оператори INSERT SQL займають значно більше місця, ніж бінарне сховище бази даних.
- Повільний імпорт величезних багатогігабайтних дампів баз даних, якщо перебудову індексів не вимкнено.
Цікаві технічні факти
- SQL спочатку називався 'SEQUEL' (Structured English Query Language), але був скорочений до SQL через спір щодо торгової марки з авіабудівною компанією Hawker Siddeley.
- Офіційний стандарт ISO вимовляє його як окремі літери 'S-Q-L', але мільйони розробників розмовно вимовляють його як 'сиквел'.
- За оцінками, SQLite, що використовує синтаксис SQL, встановлено на понад 1 трильйоні пристроїв у всьому світі.
Поширені технічні запитання
Що таке файл .sql?
Файл .sql: це звичайний текстовий скрипт, що містить команди SQL для створення таблиць, встановлення зв'язків і вставлення рядків даних у реляційну базу даних.
Чи можу я конвертувати файли дампу SQL у CSV або JSON?
Так. File2File.app може аналізувати файли дампу бази даних .sql і безпосередньо експортувати таблиці у файли CSV із табличними даними або структуровані документи JSON.
Чому мій файл MySQL .sql не працює в PostgreSQL?
Різні системи баз даних мають власні відмінності в діалектах (наприклад, типах даних та екрануванні лапок). Під час перенесення між рушіями баз даних потрібно перетворювати синтаксис відповідного діалекту.
Пов'язані пари конвертації SQL
Перетворення файлу бази даних SQLite на текстовий SQL-дамп створює з бінарної бази читабельні текстові команди для перенесення даних та імпорту на сервер.
Перетворення текстового скрипту дампу SQL на експорт даних JSON перетворює жорсткі таблиці реляційної бази даних на гнучкі вкладені об'єкти для сучасних вебзастосунків.
Перетворюйте скрипти резервного копіювання реляційних баз даних на плоскі табличні електронні таблиці для простого аналізу даних та звітності.
Перетворіть підтримувану резервну копію SQL Server у форматі .bak на текстовий SQL-скрипт для перевірки або перенесення даних.
Конвертація нестисненого звичайного текстового SQL-скрипта в оптимізований нативний файл резервної копії бази даних зменшує розмір сховища та прискорює час відновлення сервера.