Apa yang dimaksud Robert C. Martin dengan SQL tidak perlu? [Tutup]


45

Saya telah membaca / menonton banyak konten Robert C. Martin. Saya telah menemukan dia mengatakan SQL tidak perlu karena solid state drive. Ketika saya mencari sumber lain untuk mendukung ini saya mendapatkan banyak artikel acak yang menggambarkan perbedaan kinerja SQL antara hard drive dan solid state drive (yang terkait tetapi tidak apa yang saya coba untuk riset).

Pada akhirnya, saya tidak mengerti apa yang dia coba lakukan. Apakah dia mengatakan mengganti SQL dengan teknologi No-SQL? Apakah dia mengatakan menyimpan data dalam file dalam sistem file? Atau apakah dia hanya ingin orang berhenti menggunakan SQL / Database Relasional karena serangan SQLi? Saya khawatir saya kehilangan poin yang dia coba buat.

Saya akan memberikan beberapa tautan di sini sehingga Anda dapat membaca langsung dari benaknya:

  1. Tabel Bobby
  2. Kuliah Arsitektur Bersih

Pertama, ia menyatakan bahwa SQL harus dihapus dari sistem sepenuhnya.

Solusinya. Satu-satunya solusi. Adalah untuk menghilangkan SQL dari sistem sepenuhnya. Jika tidak ada mesin SQL, maka tidak ada serangan SQLi.

Dan meskipun dia berbicara tentang mengganti SQL dengan API, saya TIDAK berpikir dia bermaksud meletakkan SQL di belakang API karena kutipan sebelumnya dan apa yang dia katakan sebelumnya dalam artikel.

Kerangka kerja tidak menangani masalah ini; ...

Catatan: Dengan mengatakan SQL, saya cukup yakin Robert berarti sebagian besar basis data relasional. Mungkin tidak semuanya kecuali kebanyakan. Bagaimanapun, kebanyakan orang menggunakan SQL anyways. begitu...

Jika SQL tidak digunakan untuk menyimpan data, lalu apa yang harus kita gunakan?

Sebelum menjawab itu, saya juga harus perhatikan. Robert menekankan bahwa solid state drive harus mengubah alat yang kami gunakan untuk bertahan data. Jawaban Søren D. Ptæus menunjukkan ini.

Saya juga harus merespons ke grup "tetapi integritas data". Setelah beberapa penelitian lebih lanjut, Robert mengatakan kita harus menggunakan database transaksional seperti datomic . Kemudian CRUD berubah menjadi CR (buat dan baca) dan transaksi SQL hilang sama sekali. Integritas data tentu saja penting.

Saya tidak dapat menemukan pertanyaan yang mencakup semua ini. Saya kira saya sedang mencari alternatif yang sesuai dengan pedoman Robert. Datomic adalah satu tetapi apakah itu? Opsi apa yang cocok dengan pedoman ini? Dan apakah mereka benar-benar bekerja lebih baik dengan solid state drive?


5
@ christo8989 - "Apa yang dia maksud dengan mengganti SQL dengan API?". Saya menafsirkannya berarti bahwa Anda tidak memiliki bahasa permintaan tekstual (yang diteruskan ke mesin SQL) di seluruh basis kode Anda. Anda menyembunyikan ini di belakang API yang hanya memaparkan mekanisme aman untuk menggambarkan kueri. Di dalam API sesuatu harus menghasilkan perintah ke mesin SQL, tetapi itu adalah area permukaan yang lebih kecil di mana Anda dapat menegakkan penggunaan pengikatan parameter, dll, mengontrol siapa yang membuat perubahan, dll.
andrew

42
Tapi, tapi, tapi ... SQL adalah API. Ini adalah API untuk RDBMS. Kebetulan saja itu adalah API yang sangat kuat yang dapat dengan mudah disalahgunakan.
Bart van Ingen Schenau

25
Jika Anda membuat API DB yang tidak memiliki antarmuka tekstual, cepat atau lambat beberapa programmer miskin akan menulis kode yang terlihat seperti ini: eval(request.GET["table_name"] + ".get(pk=" + request.GET["pk"] + ")")). Bukan SQL yang benar-benar salah, tetapi programmer yang buruk dan bodoh.
Lie Ryan

6
@JimmyJames SQL adalah bahasa ya, tapi itu tidak berarti itu bukan API. SQL adalah bahasa yang menyediakan API untuk mengakses beberapa penyimpanan yang mendasarinya.
Kubik

5
@nocomprende SQL selalu dirancang untuk digunakan untuk aplikasi. Kalau tidak begitu, itu akan sia-sia. Intinya selalu adalah memberikan aplikasi beberapa cara untuk menyimpan dan mengambil data tanpa mengacaukan format kustom yang aneh atau bahkan harus peduli banyak tentang bagaimana data disimpan.
Kubik

Jawaban:


74

Bob Martin jelas melebih-lebihkan untuk menegaskan maksudnya. Tapi apa gunanya?

Apakah dia hanya ingin orang berhenti menggunakan SQL / Database Relasional karena serangan SQLi?

Setahu saya, dalam posting blog itu (tautan pertama Anda), Martin mencoba meyakinkan orang untuk berhenti menggunakan SQL, tetapi bukan basis data relasional. Ini adalah dua hal yang berbeda .

SQL adalah bahasa yang sangat kuat, dan ini distandarisasi sampai tingkat tertentu. Hal ini memungkinkan untuk membuat pertanyaan dan perintah yang kompleks dengan cara yang sangat kompak, dengan cara yang mudah dibaca, dimengerti, mudah dipelajari. Itu tidak tergantung pada bahasa pemrograman lain, sehingga dapat digunakan untuk sebagian besar programmer aplikasi, tidak peduli apakah mereka lebih suka Java, C, C ++, C #, Python, Ruby, JavaScript, Basic, Go, Perl, PHP, atau yang lainnya.

Namun, kekuatan ini dikenakan biaya : menulis query / perintah SQL yang aman lebih sulit daripada menulis yang tidak aman. API yang aman harus memudahkan untuk membuat kueri yang aman "secara default". Yang berpotensi tidak aman harus membutuhkan lebih banyak mental atau setidaknya upaya mengetik. Itulah IMHO mengapa Martin mengomel terhadap SQL dalam bentuk saat ini.

Masalahnya bukan hal baru, dan ada API yang lebih aman daripada SQL standar untuk mengakses database relasional. Misalnya, semua ATAU pemetaan yang saya tahu berusaha menyediakan API semacam itu (meskipun mereka biasanya dirancang untuk tujuan utama lainnya). Varian SQL statis membuatnya sulit untuk membuat kueri dinamis dengan data input yang tidak disanitasi (dan itu bukan penemuan baru: SQL tertanam, yang sering menggunakan SQL statis, berusia sekitar 30 tahun).

Sayangnya, saya tidak mengetahui adanya API yang fleksibel, standar, dewasa, mandiri bahasa dan juga sekuat SQL, terutama SQL dinamis. Itu sebabnya saya memiliki keraguan tentang saran Martin tentang "tidak menggunakan SQL" sebagai cara realistis untuk memecahkan masalah yang disebutkan. Jadi bacalah artikelnya sebagai pemikiran ke arah yang benar, bukan sebagai "praktik terbaik" yang bisa Anda ikuti secara membabi buta mulai besok.


2
Setidaknya kita dapat menghindari menggunakannya untuk operasi penulisan apa pun biasanya dengan apa yang disediakan oleh ORM. Adapun permintaan database, Anda sudah bisa melakukan beberapa hal tanpa menulis SQL Anda sendiri. Saat ini hanya penggunaan "maju" dari kemampuan database yang harus menulis SQL atau penggunaan tipe data yang kompleks (grafik, data geografis, rekursif).
Walfrat

7
Martin secara khusus berpendapat bahwa API yang digunakan tidak boleh sekuat SQL; Argumennya bahwa kekuatan SQL adalah masalahnya, bukan fitur. API yang diperdebatkannya harus spesifik untuk aplikasi, dan hanya sefleksibel dan sekuat aplikasi yang benar-benar dibutuhkan, bukan lebih. Dia secara khusus membantah menciptakan bahasa query berbasis string lain.
Cubic

3
@Cubic: solusi apa pun untuk masalah yang disebutkan oleh Martin mungkin harus kurang kuat atau kurang mudah digunakan daripada SQL - itulah berkah dan kutukan mereka.
Doc Brown

1
@Barmar: SQL hampir setinggi yang Anda bisa dapatkan, dan Bob menyatakan bahwa itu sebenarnya tidak aman.
Robert Harvey

3
@ christo8989: Saya rasa tidak masuk akal untuk mencoba menulis satu jawaban sebagai jawaban atas semua yang pernah ditulis atau dikatakan Martin dalam kariernya. Jawaban saya adalah satu untuk pertanyaan berikan dalam judul Anda, menjelaskan sebagian besar bagaimana posting blog di tautan pertama yang Anda berikan harus diartikan IMHO.
Doc Brown

57

Pendapat Bob Martin hanya itu; pendapat satu orang.

Seorang programmer diharapkan untuk memahami sistem yang ditulisnya dengan cukup baik untuk melakukan perawatan yang wajar tentang keamanan dan kinerjanya. Itu berarti, jika Anda berbicara dengan database SQL, Anda melakukan apa yang dikatakan situs web Bobby Tables : Anda membersihkan data input Anda. Ini berarti bahwa Anda meletakkan database SQL Anda pada mesin yang menjanjikan kinerja yang memadai. Ada cara-cara yang sangat terkenal dan dipahami untuk melakukan hal-hal ini, dan sementara mereka tidak menjamin keamanan absolut atau kinerja ideal, tidak juga melakukan hal lain.

Pernyataan bahwa kita tidak perlu SQL lagi karena kita sekarang memiliki SSD hanya bermata-mata. SQL tidak ditemukan karena hard drive berkecepatan tinggi belum ada; itu diciptakan karena kami membutuhkan cara standar industri untuk mengekspresikan konsep pengambilan data. Sistem basis data relasional memiliki banyak kualitas lain selain kecepatan dan keamanan yang menjadikannya ideal untuk operasi bisnis; khususnya, ACID . Integritas data setidaknya sama pentingnya dengan kecepatan atau keamanan, dan jika Anda tidak memilikinya, lalu apa gunanya mengamankan data yang buruk atau mengambilnya secepat mungkin?

Sebelum Anda mengambil histeria satu orang sebagai Injil, saya sarankan Anda belajar tentang keamanan aplikasi dan sistem dan kinerja dengan persyaratan mereka sendiri, bukan dengan membaca artikel Internet acak. Ada banyak hal lain untuk keamanan, kinerja, dan desain sistem yang tangguh daripada sekadar "hindari teknologi ini."

Kami tidak melarang pisau dapur karena beberapa orang yang malang berhasil memotong jari mereka secara tidak sengaja.


16
Saya tidak menafsirkan artikel Martin sebagai menganjurkan meninggalkan RDBMS, melainkan menggunakan cara alternatif untuk berinteraksi dengan mereka, misalnya LINQ-to-SQL atau API Kriteria JPA, daripada langsung menyandikan atau memanipulasi string SQL dalam kode sumber kami.
Jules

27
Jadi kita tidak boleh secara membabi buta mengikuti apa yang dia katakan ... tapi apa yang dia katakan ?
TRiG

33
Satu hal yang saya sangat tidak suka tentang komunitas di sini adalah, segera setelah Anda mengajukan pertanyaan tentang melakukan sesuatu Kode Bersih / Paman Bob-cara , adalah orang-orang menukik memberi tahu Anda bagaimana Anda harus melakukan sesuatu yang berbeda . "Bagaimana cara melukis seperti van Gogh?" - "van Gogh salah, Anda harus melukis seperti Picasso sebagai gantinya".
R. Schmitz

21
membersihkan data input untuk menghindari serangan injeksi harus menjadi opsi cadangan setelah menggunakan metode parametrized untuk memisahkan kode dari input.
ratchet freak

17
Semua teknologi hancur dan pada dasarnya cacat. Ini hanya masalah waktu saja. Sementara itu, kami memiliki hal-hal yang perlu kami lakukan, dengan teknologi kami yang cacat dan hancur.

15

Apa yang sebenarnya dia katakan?

Apakah dia mengatakan mengganti SQL dengan teknologi No-SQL?

TL; DR: Ya (semacam)

Dalam sebuah pembicaraan yang lebih baru daripada yang Anda tautkan pada dasarnya pada topik yang sama ia berkata: "Database adalah detail. Mengapa kita memiliki database?" .

Dia mengklaim basis data datang untuk membuat akses data dari disk pemintalan lebih mudah, tetapi di masa depan "[...] tidak akan ada disk" berkat teknologi baru dan apa yang disebutnya "RAM persisten" dan akan lebih mudah untuk menyimpan data menggunakan struktur yang digunakan programmer, seperti hashtable atau tree.

Dia melanjutkan untuk memprediksi bahwa basis data relasional secara keseluruhan sebagian besar akan hilang karena kompetisi baru mereka:

Jika saya adalah Oracle, saya akan sangat takut karena alasan keberadaan saya menguap dari bawah saya. [...] Alasan keberadaan basis data menghilang.

Mungkin akan ada beberapa tabel relasional yang bertahan, tetapi sekarang ada beberapa kompetisi yang sehat .

Jadi tidak, baginya itu bukan hanya tentang injeksi SQL, meskipun ia berpendapat SQL secara inheren cacat dalam hal ini .


Catatan penulis:

Pernyataan dalam posting ini hanya kutipan untuk memahami pandangan Robert C. Martin tentang topik ini dan tidak mewakili pendapat penulis. Untuk sudut pandang yang lebih berbeda, lihat jawaban Robert Harvey .


2
'Persistent RAM' tampaknya hanya membahas penggunaan database untuk membuat serialisasi keadaan aplikasi saat ini tanpa memperhatikan kompatibilitas ke depan atau ke belakang. Tentu, beberapa database digunakan dengan cara itu tetapi tidak berarti semuanya (saya sadar Martin mengatakan ini, bukan Anda).
Kubik

7
Jadi, Martin sebenarnya mengatakan bahwa satu-satunya titik basis data adalah abstrak di atas penyimpanan yang lambat? Wow. Maka ini mendukung jawaban Robert Harvey: Pendapatnya harus diambil dengan sebutir garam besar. Sebagai contoh, sudut pandang ini gagal untuk mempertimbangkan bahwa nilai DB mempertahankan model data yang konsisten dan persisten. Gagasannya tentang struktur data dalam "RAM persisten" (SSD?) Keduanya lambat dan membuka kemungkinan kehilangan data, bahkan DB NoSQL sering menggunakan struktur data penjurnalan dan data yang tidak dapat diubah untuk secara aman memperbarui catatan persisten.
amon

3
@amon Ya, Robert Harvey benar menawarkan sudut pandang yang lebih berbeda. Tetapi karena OP bertanya secara spesifik tentang apa yang Robert C. Martin coba katakan, saya menyalin sebagian pembicaraannya yang "baru".
Søren D. Ptæus

3
@amon - lihat kalimat pertama jawaban Doc Brown di atas. Martin sering membuat pernyataan yang sangat berlebihan dari maksudnya untuk menyampaikannya. Dia tidak bermaksud bahwa semua operasi basis data dapat digantikan oleh penyimpanan di dalam memori, lebih dari sekadar berarti memiliki komponen aplikasi Anda yang menyentuh SQL dalam beberapa bentuk adalah risiko keamanan yang cukup besar sehingga harus dihindari di semua kasus, namun di muka kata-katanya ia dapat diartikan sebagai mengatakan itu. Tapi yang dia benar-benar coba lakukan adalah membuat semua orang berhenti dan berpikir: apakah SQL / RDBMS tepat untuk aplikasi saya?
Jules

12
@ Jules Saya mengerti bahwa dia sering melebih-lebihkan. Tetapi mengingat jangkauan dan reputasinya, sangat tidak membantu bahwa "Paman Bob" tidak menjelaskan kapan dia melebih-lebihkan dan di mana dia sebenarnya mengatakan apa yang dia maksudkan. Jika dia seharusnya mengajarkan sesuatu, tidak mungkin untuk menebak-nebak dan menafsirkan kembali semua yang dia katakan sampai masuk akal , terutama karena dia tidak mencerminkan atau mengkritik ide-idenya sendiri. Pada titik tertentu, lebih mudah untuk mengatakan "jangan dengarkan dia", atau bahkan: Paman Bob Dianggap Berbahaya .
amon

11

SQL adalah detail. Pengetahuan detail tidak harus disebarkan.

Karena SQL digunakan di semakin banyak tempat dalam kode Anda, kode Anda menjadi semakin tergantung padanya.

Saat Anda mempelajari semakin banyak trik SQL, Anda memecahkan semakin banyak masalah menggunakan SQL. Ini berarti bahwa beralih ke API lain untuk bertahan melibatkan lebih dari sekadar menerjemahkan. Anda harus menyelesaikan masalah yang tidak Anda sadari.

Anda mengalami ini bahkan beralih antara Database. Satu menawarkan fitur mewah whizzbang 5 sehingga Anda menggunakannya di sejumlah tempat hanya untuk mengetahui fitur mewah whizzbang 5 adalah milik dan sekarang Anda memiliki masalah lisensi yang akan menghabiskan banyak uang. Jadi Anda melakukan banyak pekerjaan menggali di mana-mana Anda menggunakan fitur 5 dan menyelesaikan masalah sendiri hanya untuk mencari tahu nanti Anda juga menggunakan fitur whizzbang 3.

Salah satu hal yang membuat Java begitu portabel adalah fitur-fitur tertentu dari CPU tidak tersedia. Jika tersedia, saya akan menggunakannya. Dan tiba-tiba ada CPU yang kode Java saya tidak akan berfungsi karena mereka tidak memiliki fitur-fitur itu. Ini sama dengan fitur basis data.

Mudah mengorbankan kemerdekaan Anda tanpa menyadarinya. SQL adalah pilihan bukan yang diberikan. Jika Anda membuat keputusan untuk menggunakan SQL maka buatlah di satu tempat. Buatlah dengan cara yang bisa dibuat-buat.

Fakta bahwa SQL memiliki masalah keamanan dan bahwa kita akan beralih ke model memori yang persisten tidak berarti SQL akan hancur. Ini hanya mengarahkan titik bahwa itu pilihan. Jika Anda ingin mempertahankan hak untuk membuat pilihan itu, Anda harus melakukan pekerjaan itu.


Mungkin perlu dicatat bahwa pergerakan basis data tahun 80-an dan Paman Bob memiliki sejarah yang agak buruk. Dia memiliki semua masalahnya diselesaikan dengan sistem file datar ketika manajemen memaksa admin database ke dalam hidupnya. Acara ini mendorongnya ke dalam karir konsultan bintangnya. (Dia menceritakan kisah ini di salah satu buku awalnya yang bersih, lupakan yang mana). Dia tahu bagaimana menyelesaikan masalah tanpa DB dan memiliki sedikit kesabaran untuk mereka yang bertindak seperti menggunakannya adalah sesuatu yang diberikan.

Dia juga bercerita tentang menunda menambahkan DB ke aplikasi sampai menit terakhir ketika pelanggan menuntutnya, dan menambahkannya dalam sehari sebagai fitur opsional. Dugaan saya adalah dia melihat cara sebagian besar dari kita menggunakan DB sebagai kecanduan. Dia berusaha menunjukkan kepada kita bagaimana menghentikan kebiasaan itu.


1
Astaga, Einstein, tentu saja.

1
Ah, tidak tahu Einstein tahu Bob. Atau Bob adalah Tuhan. Meskipun kedengarannya seperti itu memiliki bakat untuk sedikit standup yang menyenangkan.
candied_orange

9
@nocomprende Anda menjalani diet poster motivasi yang mantap?
candied_orange

2
Tapi Bob adalah Tuhan. Setidaknya untuk beberapa orang.
Peter Mortensen

3
Saya menolak untuk percaya bahwa Tuhan itu bagus dalam berbicara di depan umum.
candied_orange

5

Kutipan dari kutipan pertama Anda adalah (penekanan milikku),

Solusinya. Satu-satunya solusi. Adalah untuk menghilangkan SQL dari sistem sepenuhnya. Jika tidak ada mesin SQL, maka tidak ada serangan SQLi.

Apa yang akan menggantikan SQL? API tentu saja! Dan BUKAN API yang menggunakan bahasa tekstual. Alih-alih, API yang menggunakan kumpulan struktur data dan panggilan fungsi yang tepat untuk mengakses data yang diperlukan.

Kata-kata kasar menentang membiarkan programmer aplikasi menggunakan SQL.

Perbaikan yang disarankan adalah membiarkan mereka menggunakan API sebagai gantinya: yang bukan SQL dan tidak mengizinkan injeksi.

IMO, contoh-contoh API tersebut mungkin termasuk:

  • http://bobby-tables.com/csharp menyarankan pemrogram C # dapat menggunakan API ADO.NET.

    Itu bukan contoh sempurna karena ADO.NET adalah API yang luas atau dalam (yaitu kuat atau untuk tujuan umum), yang juga memungkinkan penggunanya untuk memasukkan SQL mentah (atau mentah-ish).

  • Beberapa pengembang SQL atau administrator database menyarankan bahwa database harus dikonfigurasikan sedemikian rupa sehingga hanya mengizinkan akses melalui sejumlah prosedur yang tersimpan , dan pengembang aplikasi seharusnya tidak diizinkan untuk menulis kueri SQL mereka sendiri (berbahaya)

  • Cara lain untuk "menghilangkan SQL dari sistem" adalah dengan meletakkan database (yang memaparkan SQL) pada beberapa sistem lain , diakses melalui REST API atau yang serupa.

Jadi, IMO, solusi keseluruhan atau sistem [s] masih dapat menggunakan database (terutama mengingat bahwa mesin database mengimplementasikan properti ACID yang berguna, dan skala dengan baik dan seterusnya, mungkin bodoh untuk mencoba melakukannya tanpa satu, atau menulis satu aplikasi khusus).

Persyaratan kata-kata kasar terpenuhi jika SQL API database disembunyikan dari pengembang aplikasi, di belakang beberapa API lainnya (misalnya ADO, mungkin ORM, layanan Web, atau apa pun).

Lebih umum saya kira itu berarti memiliki DAL khusus aplikasi ("lapisan akses data" atau "lapisan abstraksi basis data"). DAL mengisolasi aplikasi dari perincian tentang bagaimana dan di mana data disimpan dan / atau diambil. DAL mungkin atau mungkin tidak diimplementasikan menggunakan database SQL.


Saya bekerja pada produk yang melakukan ini tepat 30 tahun yang lalu. Dan, database yang mendasarinya bahkan tidak mendukung SQL (belum). Dan, set tabel terkait disimpan dalam (tunggu ...) database. Orang yang datang dengan itu benar-benar pintar. Tidak lagi seorang programmer.

Saya suka jawaban ini tapi saya pikir dia mungkin tidak mengatakan ini. Dia juga menyatakan, "Kerangka kerja tidak menangani masalah ...". Dari jawaban Anda, sepertinya Anda mengatakan menggunakan Linq-to-Sql tidak apa-apa tapi bukankah itu kerangka kerja yang menangani masalah ini?
christo8989

@ christo8989 Saya tidak tahu. Dia menyebutkan Hibernate sebagai contoh kerangka kerja yang tidak akan menangani masalah ini. Dan memang OWASP mengatakan , "Hibernate tidak memberikan kekebalan terhadap SQL Injection, orang dapat menyalahgunakan api sesuka mereka. Tidak ada yang istimewa tentang HQL (Hibernate subset dari SQL) yang membuatnya lebih atau kurang rentan." Sedangkan beberapa API yang saya sebutkan akan menjadi isolator yang lebih baik, tidak mengekspos SQL sama sekali. Mungkin Hibernate adalah sesuatu yang dapat Anda gunakan untuk mengimplementasikan DAL (tetapi bukan merupakan DAL isolasi penuh).
ChrisW

1
@ christo8989 augustl.com/blog/2016/... menunjukkan bahwa Datomic (hanya) pembungkus / lapisan lain di sekitar database (mungkin-SQL) - "Datomic tidak menulis langsung ke sistem file. Sebaliknya, Anda dapat menggunakan nomor database yang berbeda sebagai backend penyimpanan untuk Datomic: Setiap database SQL JDBC, dll. "
ChrisW

Perlu dicatat bahwa solusi untuk menghindari injeksi SQL di ADO.NET tidak terlalu rumit - gunakan placeholder dalam SQL, gunakan parameter dalam perintah, dan tetapkan nilai parameter tersebut.
Zev Spitz

3

Semua orang tampaknya menjawab pertanyaan ini dari sudut pandang keamanan, atau dengan lensa SQL.

Saya melihat ceramah Robert Martin di mana dia menceritakan bahwa sebagai programmer, kami menggunakan banyak struktur data berbeda yang optimal untuk program khusus kami. Jadi, daripada secara universal menyimpan semua data dalam struktur tabel, kita harus menyimpan data kita dalam tabel hash, pohon, dll sehingga kita dapat mengambil data dan langsung masuk ke program.

Saya menafsirkan pesannya sebagai hanya mengatakan kita harus membuang asumsi kita saat ini tentang penyimpanan persisten sejenak untuk mempertimbangkan kemungkinan lain di masa depan daripada format tabular SQL kuno. SSD adalah solusi kandidat, tetapi bukan satu-satunya.


Apa yang mungkin dia pikirkan tentang multi-pengguna bersamaan baca / tulis data?
ChrisW

1
@ ChrisW Saya tidak berpikir ini adalah masalah implementasi, bukan ide tingkat tinggi untuk menemukan cara untuk melakukan penyimpanan data yang persisten dengan lebih baik.
Keenan

@ ChrisW Dia juga berbicara tentang basis data transaksional. Menempatkan teknologi kontrol sumber sebagai alat ketekunan Anda. Dalam hal itu, Anda hanya membuat dan membaca yang jauh lebih ramah daripada transaksi dan pembaruan.
christo8989

@Keenan Jadi dia tidak benar-benar menawarkan solusi melalui implementasi. Dia hanya mengatakan, pikirkan apa yang bisa terjadi?
christo8989

1
@ christo8989 Apakah dia secara pribadi mempelopori devolopment solusi kandidat untuk masalah penyimpanan yang terus-menerus dalam ilmu komputer, saya tidak tahu. Itu di luar ruang lingkup pertanyaan OP. Paman Bob adalah semua tentang arsitektur plug-in. Standar industri saat ini dalam pengembangan aplikasi sangat erat dengan database dan membangun aplikasi di sekitarnya, aplikasi tergantung pada db, ketika db harus bergantung pada aplikasi. Sebaliknya, Paman Bob mengusulkan bahwa 'database adalah detail' dan harus dipisahkan dan diganti.
Keenan

2

Sebenarnya, dia tidak menggunakan database dan SQL - cukup eksplisit. Referensi pertama adalah masalah yang diketahui dengan baik, referensi kedua terdengar seperti kata-kata kasar. Meskipun, saya menafsirkannya sebagai alasan yang baik untuk menggunakan database dan tidak menggunakan SQL. Dari sudut pandang saya, ini bahkan bukan saran yang masuk akal.

Sayangnya, contoh yang ia gunakan adalah contoh yang sangat dikenal dengan solusi terkenal yang kemudian ia tunjukkan. Biasanya muncul ketika seorang programmer tidak menyadari apa yang dia lakukan. Misalnya membangun string yang berisi SQL seperti:

    my $sql="select a from b where a=$ui_val;";
    prepare($sql)
    execute($sql)

sebagai lawan

    my $sql="select a from b where a=?;";
    prepare($sql)
    execute($sql,$ui_val);

Ini adalah perl DBI seperti contoh untuk ruby ​​on rails code. Kode rel yang ia sediakan mudah membingungkan antara brankas dan tidak aman. Seperti banyak ORM menyembunyikan apa yang ada di bawah SQL dan sering kali Anda berurusan dengan antarmuka yang membangun dan mengeksekusi sql untuk Anda. Bukankah ini terdengar seperti apa yang akan dilakukan API untuk Anda?

Interpretasi saya tentang referensi pertama adalah bahwa ia menyarankan agar kita mengganti masalah yang sudah diketahui dan memiliki solusi yang sudah diketahui.

Sangat disayangkan bahwa dia tidak menyebutkan bahwa jika ini dilakukan dengan benar, itu akan membuat kode lebih mudah untuk ditulis dan lebih mudah dibaca, meskipun jika dilakukan dengan baik, itu sebenarnya mungkin lebih sulit untuk ditulis dan kurang dapat dibaca. Selain itu, ia tidak menyebutkan bahwa SQL sangat mudah dibaca dan melakukan apa yang biasanya Anda harapkan.

Dia sebagian benar, pada akhirnya kita akan memiliki memori yang sangat besar dan cepat dan prosesor yang sangat cepat. Sampai kita keluar dari fisika saat ini yang membatasi komputasi, dia tidak benar.

Ya spinning disk adalah sesuatu dari masa lalu, dan kami sekarang menggunakan SSD. Disk bekerja dengan ~ 10 milidetik per transfer data, SSD bekerja dengan ~ 0,5 milidetik (500 mikrodetik) waktu akses data. RAM ada di urutan 100 nano detik, prosesor beroperasi di atas 100 detik pico. Inilah jantung mengapa kita membutuhkan basis data. Database mengelola transfer data antara disk pemintalan atau SSD dengan memori utama. Munculnya SSD belum menghilangkan kebutuhan akan database.


4
"BERHENTI MENGGUNAKAN SQL" (dikutip dari tautan pertama) terdengar sangat seperti dia mengatakan tidak menggunakan SQL, untuk pemahaman saya.
Doc Brown

6
Ini adalah masalah urutan kata. Sebenarnya ini awalnya sebuah telegram: MENGGUNAKAN SQL STOP

6
@nocomprende Jadi Anda mengatakan bahwa dia adalah korban dari kondisi balapan? Baiklah, oops. Dia bisa menghindarinya dengan menggunakan transaksi SQL.
Konrad Rudolph

Mungkin itu adalah campuran yang sangat singkat dari Visual Basic dan Fortran. Di mana semuanya berakhir?

1
@KonradRudolph: Yah, saya pikir kami akan setuju bahwa hampir tidak ada yang akan menggunakan TSX langsung dari perakitan. Akan ada abstraksi tingkat yang lebih tinggi. Akankah transaksi abstrak itu menjadi transaksi SQL? Saya pikir tidak. Sebagai bahasa yang ditafsirkan, SQL membawa overhead kinerja. Itu benar-benar tidak masalah ketika Anda mengakses data pada harddisk berputar. Namun tidak terjangkau ketika mengakses data dalam RAM.
MSalters

2

Menjawab

apakah dia hanya ingin orang berhenti menggunakan SQL / Database Relasional karena serangan SQLi?

Artikel 'Bobby Tables' tampaknya menyarankan bahwa ini, dan dengan sendirinya adalah alasan untuk tidak menggunakan SQL:

Solusinya. Satu-satunya solusi. Adalah untuk menghilangkan SQL dari sistem sepenuhnya. Jika tidak ada mesin SQL, maka tidak ada serangan SQLi.

Dia mungkin punya alasan lain yang dia diskusikan di tempat lain. Saya tidak akan tahu karena saya tidak benar-benar membaca banyak hal tentangnya.

Penyimpangan

Bagian ini sebenarnya bukan jawaban, tapi saya pikir pertanyaan tentang nilai SQL jauh lebih menarik (seperti yang dilakukan orang lain, tampaknya.)

Saya sudah memiliki banyak pengalaman menggunakan SQL dan saya pikir saya memiliki pemahaman yang adil tentang kekuatan dan kelemahannya. Perasaan pribadi saya adalah bahwa itu sudah digunakan secara berlebihan dan dilecehkan, tetapi gagasan bahwa kita seharusnya tidak pernah menggunakannya agak konyol. Gagasan bahwa kita harus memilih 'SQL always' atau 'SQL never' adalah dikotomi yang salah.

Sejauh injeksi SQL menjadi argumen untuk tidak menggunakan SQL, itu menggelikan. Ini adalah masalah yang dipahami dengan baik dengan solusi yang cukup sederhana. Masalah dengan argumen ini adalah bahwa SQLi bukan satu-satunya kerentanan yang ada. Jika Anda berpikir bahwa menggunakan API JSON membuat Anda aman, Anda akan terkejut.

Saya pikir setiap pengembang harus menonton video ini berjudul "Friday the 13th: Menyerang JSON - Alvaro Muñoz & Oleksandr Mirosh - AppSecUSA 2017"

Jika Anda tidak memiliki waktu atau kecenderungan untuk melihatnya, inilah intinya: Banyak perpustakaan deserialisasi JSON memiliki kerentanan eksekusi kode jauh. Jika Anda menggunakan XML, Anda harus lebih khawatir. Melarang SQL dari arsitektur Anda tidak akan membuat sistem Anda aman.


Tidak ada yang mengklaim bahwa pelarangan SQL akan membuat sistem Anda aman. Paman Bob mengklaim bahwa itu membuat sistem Anda lebih aman, dan mengingat bahwa injeksi SQL tetap menjadi risiko terbesar dalam keamanan aplikasi web selama lebih dari satu dekade sekarang, saya pikir Anda tidak boleh dengan mudah mengabaikan kebutuhan industri untuk meningkatkan cara berbicara dengan basis data. .
meriton - saat mogok

@meriton Maaf, tapi "solusi, satu-satunya solusi" tampaknya cukup jelas. Solusi untuk masalah SQLi dikenal dan cukup sederhana. Orang-orang yang tidak dapat diganggu menggunakan pernyataan persiapan akan membuat sistem tidak aman terlepas dari apakah mereka berhenti menggunakan SQL. Ini adalah orang-orang yang tidak profesional yang perlu mulai mengikuti praktik dasar yang baik atau mendapatkan pekerjaan baru.
JimmyJames

2

Saya hanya ingin membahas pernyataan singkat:

Atau apakah dia hanya ingin orang berhenti menggunakan SQL / Database Relasional karena serangan SQLi?

Tidak. Itu anggapan yang salah. Kita tidak bisa mengatakan kita harus berhenti menggunakan mobil, karena mereka bertanggung jawab atas orang yang meninggal dalam kecelakaan mobil. Dengan cara yang sama, database SQL / relasional (atau apa pun dalam konteks ini, seperti RDBMS) tidak bertanggung jawab atas muatan SQL berbahaya yang dapat dilakukan oleh penyerang di aplikasi web Anda. Saya yakin penulis tidak bermaksud demikian, karena ada lembar contekan pencegahan injeksi SQL untuk tujuan ini.


2
Mobil otomatis akan mencegah sekitar 98% kecelakaan mobil. Kita perlu percaya mesin lebih , heh heh heh.

3
”Kami tidak dapat mengatakan kami harus berhenti menggunakan mobil [kecuali karena keadaan khusus dan / atau dikendalikan dengan cermat] karena mereka bertanggung jawab atas orang yang meninggal dalam kecelakaan mobil.” - Uhm. Kami benar - benar dapat mengatakan itu. Dan banyak orang yang masuk akal melakukannya.
Konrad Rudolph

1
Anda pada dasarnya mengatakan: Aplikasi yang dikembangkan di Java diretas sehingga kita harus berhenti menggunakan Java . Downvoting sudah cukup dan untuk sisanya, saya di sini bukan untuk mengajarkan Anda akal sehat. @KonradRudolph
Billal Begueradj

2
@BillalBEGUERADJ Itu adalah persamaan yang agak keliru (karena tidak ada yang aman dari peretasan) tetapi juga tidak sepenuhnya jauh: ada bahasa yang, secara seimbang, tidak boleh digunakan karena ada alternatif yang lebih baik; misalnya, jika Anda menggunakan C di luar konteks pemrograman sistem, Anda salah melakukannya. Pokoknya, saya tidak downvote jawaban Anda tetapi adalah salah: karena bertentangan dengan apa yang Anda klaim, itulah apa yang Bob Martin mengatakan (sebagai jawaban lain menunjukkan).
Konrad Rudolph

2

Masalah Martin tampaknya dengan programmer membangun SQL dinamis langsung dari input pengguna, seperti (maafkan saya, saya terutama seorang programmer C dan C ++):

sprintf( query, "select foo from bar where %s;", user_input );

yang benar - benar resep untuk mulas (maka strip Bobby Tables ). Setiap pemrogram yang menempatkan kode seperti itu dalam sistem produksi berhak mendapatkan paddlin '.

Anda dapat mengurangi (jika tidak sepenuhnya menghilangkan) masalah dengan menggunakan pernyataan yang disiapkan dan membersihkan input Anda dengan benar. Jika Anda dapat menyembunyikan SQL di belakang API sedemikian rupa sehingga programmer tidak secara langsung membuat string kueri, jauh lebih baik (yang merupakan bagian dari apa yang disarankan Martin).

Tetapi untuk menghilangkan SQL sepenuhnya, saya tidak berpikir itu praktis atau diinginkan. Model relasional bermanfaat , itu sebabnya mereka ada di tempat pertama, dan SQL mungkin merupakan antarmuka terbaik untuk bekerja dengan model relasional.

Seperti biasa, ini masalah menggunakan alat yang tepat untuk pekerjaan itu. Jika aplikasi keranjang belanja Anda tidak memerlukan model relasional penuh, maka jangan gunakan model relasional (artinya Anda tidak perlu menggunakan SQL). Untuk saat-saat Anda membutuhkan model relasional, maka Anda hampir pasti akan bekerja dengan SQL.


Meskipun sprintftidak mengandung jenis sanitasi yang diperlukan SQL, fungsi-fungsi yang dirancang khusus untuk tujuan ini dilakukan, dan sangat aman. Contoh: SqlQuery dalam Entity Framework .
Robert Harvey

@ RobertTarvey: Saya akan berasumsi itu masalahnya. Untuk bagian saya, saya kebanyakan melakukan pekerjaan sisi server di C dan C ++, jadi saya masih melihat sesekali melihat (untungnya jarang) contoh orang-orang hanya sprintf-ing SQL dinamis, yang Bukan Bagaimana Anda Melakukannya.
John Bode

1

Dua sumber yang Anda tautkan menyampaikan pesan yang berbeda:

Posting blog mengatakan bahwa logika akses data tidak boleh ada sebagai teks saat runtime, jangan sampai dicampur dengan input pengguna yang tidak terpercaya. Artinya, posting blog mengutuk menulis pertanyaan dengan merangkai string.

Ceramahnya berbeda. Perbedaan pertama adalah dalam nada: Kuliah berspekulasi dan menimbulkan pertanyaan, tetapi tidak mengutuk. Dia tidak mengatakan bahwa database itu jahat, tetapi menantang kita untuk membayangkan kegigihan tanpa database. Dia berpendapat bahwa dalam 30 tahun sejak database relasional menjadi luas banyak hal telah berubah, dan menyoroti dua yang mungkin memengaruhi pilihan teknologi ketekunan kami:

  • ruang penyimpanan telah meningkat sekitar 1 juta - dengan harga yang sebanding! Akibatnya, penyimpanan tidak perlu dihemat, dan khususnya, tidak perlu lagi dihapus. Dengan menggunakan penyimpanan tambahan saja, kontrol konkurensi dapat disederhanakan karena kunci baca tidak diperlukan. Ini dapat meniadakan kebutuhan untuk transaksi.
  • waktu akses telah turun, karena sebagian besar set data sekarang sesuai dengan RAM, mengurangi latensi baca secara besar-besaran.

Apakah keadaan yang berubah ini mengubah teknologi ketekunan yang optimal? Menariknya, Paman Bob tidak mengatakan - mungkin karena dia merasa tidak ada jawaban yang benar untuk semua program. Itulah sebabnya dia memperingatkan kita untuk memperlakukan pilihan teknologi kegigihan kita sebagai detail daripada mengabadikannya menjadi loh batu dan meneruskannya sebagai hikmat yang diterima kepada rekan-rekan kita.

Apakah ada alternatif?

Menulis logika akses data tanpa string sepenuhnya dimungkinkan. Di tanah Jawa, Anda mungkin menggunakan QueryDSL , di mana kueri dideskripsikan menggunakan API fasih-jenis yang dihasilkan dari skema database Anda. Kueri seperti itu mungkin terlihat sebagai berikut:

JPAQuery<?> query = new JPAQuery<Void>(entityManager);
Customer bob = query.select(customer)
  .from(customer)
  .where(customer.firstName.eq("Bob"))
  .fetchOne();

Seperti yang Anda lihat, logika kueri tidak dinyatakan sebagai String, yang dengan jelas memisahkan struktur tepercaya dari kueri dari parameter yang tidak terpercaya (dan tentu saja, QueryDSL tidak pernah menyertakan parameter ke dalam teks kueri, tetapi menggunakan pernyataan yang disiapkan untuk memisahkan kueri untuk parameternya di tingkat JDBC). Untuk mencapai injeksi SQL dengan QueryDSL, Anda harus menulis parser Anda sendiri untuk mengurai string dan menerjemahkannya ke pohon sintaks, dan bahkan jika Anda melakukannya, Anda mungkin tidak akan menambahkan dukungan untuk hal-hal buruk seperti select ... into file. Singkatnya, QueryDSL membuat injeksi SQL tidak mungkin dilakukan, dan juga meningkatkan produktivitas programmer dan meningkatkan keamanan refactoring. Mencegah risiko terbesar terhadap keamanan aplikasi web, yang telah ada cukup lama untuk memunculkan lelucon, dan mendorong produktivitas pengembang? Saya berani mengatakan bahwa jika Anda masih menulis kueri sebagai string, Anda salah melakukannya.

Adapun alternatif untuk basis data relasional, sangat penasaran untuk mengetahui bahwa kontrol multi-versi postgres 'postgres' adalah struktur data yang hanya ditambahkan oleh Paman Bob, meskipun ia mungkin lebih memikirkan toko acara , dan sumber acara pola secara umum, yang juga cocok dengan gagasan menjaga kondisi saat ini di RAM.

Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.