Apakah alat ini?
Membenih pangkalan data ujian, memuatkan eksport hamparan ke dalam jadual, atau berpindah dataset kecil selalunya bermula dengan cara yang sama: anda ada fail CSV dan anda perlukan SQL. Alat ini menghurai CSV anda (menggunakan baris header sebagai nama lajur) dan membina satu kenyataan INSERT INTO yang meliputi setiap baris data, sedia untuk ditampal ke dalam klien pangkalan data.
Nilai string dibalut dengan petikan tunggal dengan petikan dalaman dilepaskan dengan digandakan (jadi O'Brien menjadi O''Brien), iaitu peraturan pelepasan standard yang dikongsi oleh MySQL, PostgreSQL dan SQLite. Sel CSV kosong ditulis sebagai kata kunci SQL NULL dan bukannya rentetan kosong — itu pilihan sengaja, kerana sel kosong dalam hamparan biasanya bermaksud "tiada nilai" dan bukannya "sekeping teks kosong", dan NULL itulah yang dijangkakan kebanyakan skema.
Sama ada nilai itu dipetik atau dibiarkan telanjang ditentukan oleh heuristik ringkas, bukan pengesanan jenis sebenar: jika sel yang dipotong kelihatan seperti integer atau perpuluhan biasa (secara pilihan dengan tanda tolak di hadapan), ia ditulis tanpa petikan; segala-galanya yang lain — termasuk perkara yang cuma menyerupai nombor dengan aksara tambahan, seperti nombor telefon atau poskod dengan sifar di hadapan — dipetik sebagai string. Ini mengekalkan hasil yang jujur: ia titik permulaan yang baik untuk import kecil, bukan pengganti untuk mengesahkan data anda terhadap skema jadual sebenar anda sebelum menjalankannya.
Sumber: penghuraian CSV mengikut RFC 4180, perkara paling hampir dengan standard CSV formal; penggandaan petikan tunggal untuk pelepasan string ialah konvensyen kongsi yang didokumenkan oleh MySQL, PostgreSQL dan SQLite.
Kenapa guna alat ini?
- Nama jadual tersuai — tetapkan jadual sasaran sekali, dan setiap baris menyasarkan jadual itu.
- Pelepasan string yang betul — petikan tunggal dalam nilai digandakan supaya SQL tidak rosak atau terpotong.
- Pengendalian NULL yang boleh dijangka — sel kosong menjadi NULL dan bukannya rentetan kosong, sepadan bagaimana kebanyakan pangkalan data membezakan data yang hilang.
- Sintaks SQL biasa — bentuk INSERT INTO ... VALUES ... yang dijana di sini berfungsi tanpa ubah suai dalam MySQL, PostgreSQL dan SQLite.
- 100% sisi klien — data CSV anda (yang mungkin termasuk rekod pelanggan atau data perniagaan) dihurai dan ditukar dalam pelayar anda dan tidak pernah dimuat naik ke mana-mana.
Cara menggunakannya
- Tampal data CSV dengan baris header, cth. name,age\nAlice,30\nBob,25.
- Masukkan nama jadual sasaran (lalai kepada my_table).
- Klik "Generate SQL".
- Salin kenyataan INSERT INTO atau muat turun sebagai fail .sql, kemudian jalankan terhadap pangkalan data anda.
Contoh
Input
name,age,city
Alice,30,
Bob,,NYCHasil
INSERT INTO `my_table` (`name`, `age`, `city`)
VALUES
('Alice', 30, NULL),
('Bob', NULL, 'NYC');Perhatikan sel kosong menjadi NULL (bukan rentetan kosong), dan nilai age yang kelihatan seperti nombor 30 dibiarkan tanpa petikan manakala setiap nilai teks dipetik.
Tip praktikal
- Membenih pangkalan data ujian tempatan: eksport sampel kecil sebagai CSV daripada hamparan, tukar di sini, dan jalankan kenyataan INSERT terhadap pangkalan data dev anda.
- Sentiasa semak semula jenis lajur sebelum menjalankan SQL yang dijana terhadap jadual sebenar — alat ini mengesan numerik lawan teks dengan heuristik ringkas, bukan skema sebenar anda, jadi lajur integer yang menjangka format tertentu mungkin perlu penyesuaian manual.
- Jika anda ada beribu-ribu baris, satu kenyataan INSERT berbilang-baris yang dijana alat ini tetap SQL sah, tetapi kenyataan yang sangat besar boleh terkena had saiz paket maksimum pangkalan data — pisahkan CSV kepada kelompok lebih kecil dahulu jika anda hadapi had itu.
Kenapa NULL dan bukan rentetan kosong
Kesilapan biasa apabila menulis skrip CSV-ke-SQL secara manual ialah menganggap setiap sel yang hilang sebagai rentetan kosong ''. Itu secara teknikalnya SQL sah, tetapi biasanya tidak bermaksud apa yang anda mahu: lajur yang ditakrifkan sebagai integer akan menolak '' secara terus, dan walaupun dalam lajur teks, '' secara senyap bermaksud sesuatu berbeza daripada "kami tidak tahu nilai ini" dalam kebanyakan reka bentuk skema dan pertanyaan pelaporan (semakan WHERE column IS NULL tidak akan sepadan dengan rentetan kosong, dan sebaliknya). Menggunakan NULL untuk sel kosong sepadan dengan semantik yang dijangka kebanyakan pangkalan data dan ORM, dan ia mengelakkan ralat jenis apabila lajur numerik kebetulan ada nilai hilang pada sesetengah baris.
Soalan lazim
Adakah ini berfungsi dengan setiap pangkalan data SQL?
Sintaks yang dijana — identifier dipetik dengan backtick, nilai string dipetik dengan petikan tunggal, INSERT INTO ... VALUES ... standard — biasa merentasi MySQL, PostgreSQL dan SQLite. PostgreSQL tidak semestinya memerlukan backtick sekeliling identifier (ia menggunakan petikan berganda jika petikan diperlukan langsung), tetapi nama dipetik backtick tidak berbahaya di sana juga selagi anda tiada nama lajur luar biasa yang berlanggar dengan kata terperi. Tiada satu standard SQL rasmi yang diikuti di sini — hanya sintaks yang berfungsi tanpa ubah suai merentasi pangkalan data paling biasa.
Kenapa sel kosong menjadi NULL dan bukannya rentetan kosong ''?
Ini pilihan reka bentuk yang sengaja: dalam kebanyakan eksport CSV dunia sebenar, sel kosong bermakna nilai itu tidak diketahui atau tidak terpakai, bukan secara literal sekeping teks kosong. NULL ialah apa yang dijangka kebanyakan skema pangkalan data. Jika kes penggunaan anda benar-benar memerlukan rentetan kosong sebaliknya, anda perlu edit SQL yang dijana secara manual untuk kes-kes tersebut.
Bagaimana alat ini tentukan sama ada nilai perlu petikan?
Ia heuristik ringkas, bukan pengesanan jenis sebenar: jika sel yang dipotong hanya terdiri daripada digit (dengan tanda tolak pilihan di hadapan dan paling banyak satu titik perpuluhan), ia ditulis tanpa petikan sebagai nombor. Segala-galanya yang lain dipetik sebagai string. Ini bermakna poskod seperti 00501 atau nombor telefon akan dianggap sebagai teks (kerana ia gagal corak integer ketat hanya jika ia ada aksara tambahan — sifar di hadapan sahaja masih dihurai sebagai numerik di sini, jadi semak semula identifier seperti poskod dan ID sebelum menjalankan SQL itu).
Adakah data saya dimuat naik ke mana-mana?
Tidak. Penghuraian dan penjanaan SQL kedua-duanya berlaku dalam JavaScript dalam pelayar anda — tiada apa yang dihantar ke pelayan, yang menjadikan ini selamat digunakan dengan rekod pelanggan atau perniagaan yang dieksport.
Bolehkah ia kendalikan nilai CSV yang mengandungi koma atau petikan?
Ya. CSV dihurai dengan parser medan berpetikan yang betul yang memahami koma, pemisah baris dan petikan digandakan dalam medan berpetikan — bukan pemisahan naif pada koma — jadi medan seperti "Smith, John" dibaca sebagai satu nilai, bukan dipisah kepada dua lajur.