Haruskah programmer berpengalaman tahu permintaan basis data? [Tutup]

35

Ada begitu banyak programmer di luar sana yang juga ahli dalam penulisan Query dan desain Database.

Haruskah ini menjadi persyaratan inti untuk menjadi programmer ahli atau insinyur perangkat lunak?

Meskipun ada banyak kesamaan dalam cara kueri dan kode dikembangkan, pendapat pribadi saya adalah, Kueri tampaknya memiliki Struktur yang berbeda dari Kode dan bisa sulit untuk menguasai keduanya secara bersamaan karena pendekatan yang berbeda.

database query

— Shamim Hafiz
sumber

2

Apa yang Anda maksud dengan "struktur"? Jika Anda berbicara tentang semantik, daripada memahami apa pun semantik baru seharusnya tidak menjadi masalah bagi seorang " ahli ". Menurut definisi. OTOH, hanya beberapa pengembang yang terpapar dengan basis data dan bahasa query, sisanya dari kita tidak peduli sama sekali.

— SK-logic

3

Saya pikir ini adalah asumsi yang salah: "Ada begitu banyak programmer di luar sana yang juga ahli dalam penulisan Query dan desain Database." Ada beberapa programmer yang cukup ahli dalam hal-hal ini: DBA! = SE.

— Ashley

1

Seberapa sulitkah sebenarnya menulis query database?

— Kapten Sensible

@CaptainShakespeare, sungguh bisa sangat sulit setelah Anda melewati operasi CRUD. Suatu saat Ty melakukan pelaporan yang rumit. Dan kemudian lihat permintaan penyetelan kinerja.

— HLGEM

69

Apakah atau tidak penulisan permintaan basis data menjadi persyaratan inti tergantung pada pekerjaan, tetapi database relasional ada di mana-mana dalam teknologi saat ini.

Jadi, jika saya bertemu seorang programmer yang tidak tahu bagaimana menulis query database, saya akan mengharapkan satu dari dua hal:

Mereka umumnya tidak berpengalaman.
Mereka sangat terspesialisasi dalam bidang lain (misalnya sistem tertanam) dan tidak pernah perlu mempelajarinya.

Permintaan basis data pada dasarnya berbeda dari bahasa pemrograman standar lainnya. Mereka aljabar dan dimaksudkan untuk beroperasi pada data relasional, sedangkan C # atau Java sangat penting dan beroperasi pada disk, memori, input pengguna, dll. Bahkan bahasa fungsional seperti LISP atau Haskell yang lebih aljabar dalam bentuk kurang berorientasi pada data relasional.

EDIT: Seperti yang telah ditunjukkan dalam komentar oleh saya dan orang lain, ada beberapa alasan yang valid mengapa pengembang yang berpengalaman mungkin tidak mengetahui pertanyaan basis data dengan baik:

Tim mereka menggunakan ORM / NoSQL
Tim mereka memiliki programmer DB
Kompleksitas aplikasi dalam logika bisnis, dan permintaan DB sepele
Tim mereka membagi pekerjaan sedemikian rupa sehingga beberapa programmer tidak menulis pertanyaan

Meskipun valid, peringatan ini bukan alasan meyakinkan mengapa pengembang yang berpengalaman tidak akan tahu permintaan basis data. Kecuali sangat terspesialisasi, seorang programmer harus terbiasa dengan database relasional.

Singkatnya, sebagian besar pengembang yang berpengalaman harus mengetahui permintaan basis data .

— Matthew Rodatus
sumber

1

Jadi, jika seseorang melakukan proyek non sepele yang menggunakan Database, ia diharapkan berkenalan dengan pertanyaan, bukan?

— Shamim Hafiz

3

@ Ashim, saya berharap orang ini cukup berpengalaman dengan pertanyaan kecuali orang ini adalah junior atau entry level. Mungkin orang ini hanya memiliki pengalaman beberapa tahun dan dilindungi di tim yang sangat terspesialisasi?

— maple_shaft

12

@Hamim, saya mungkin berharap begitu. Mereka masih bisa menjadi programmer yang baik. Pertanyaan seperti ini sangat sulit dijawab, karena mereka begitu banyak keberatan: mungkin tim memiliki programmer DB; mungkin non-trivalness aplikasi ada dalam logika bisnis, dan permintaan basis data sepele; mungkin mereka membagi-bagi pekerjaan sehingga programmer Anda tidak bekerja pada permintaan; dll.

— Matius Rodatus

4

Tim pengembangan saya telah mendedikasikan pemrogram PL / SQL sebagai bagian dari proyek. Jadi, sementara pemrogram. Net dapat melakukan kueri sederhana, mereka ada di sana untuk meninjau dan mengembangkan kueri yang lebih kompleks. Apalagi dengan proliferasi ORM (dan NOSQL) mengapa Anda berpikir pengembang non-SQL harus tahu pertanyaan yang kompleks.

— softveda

2

@ Matthew Rodatus: Saya telah bekerja di tempat-tempat yang memiliki perpustakaan yang mengelola kueri, sehingga secara teori dimungkinkan untuk bekerja di sana tanpa memahami SQL sederhana. Saya percaya semua pengembang kompeten dalam praktiknya.

— David Thornley

23

Setiap insinyur perangkat lunak harus memiliki pemahaman dasar tentang database dan cara menyimpan dan mengambil data menggunakan SQL, setidaknya ke tingkat di mana mereka memiliki pemahaman tentang apa ini dapat digunakan untuk (dan dengan itu saya akan memasukkan pemahaman tentang kunci, pandangan , prosedur dan pemicu tersimpan).

Tidak setiap insinyur perangkat lunak perlu menjadi seorang ahli, dan tingkat keahlian yang dibutuhkan benar-benar tergantung pada jenis perangkat lunak yang mereka fokuskan. Perangkat lunak tertanam, driver perangkat keras dan sistem operasi jarang menggunakan SQL, tetapi perangkat lunak aplikasi (baik berbasis web atau desktop atau layanan / daemon) menggunakan basis data setiap saat.

— wolfgangsz
sumber

1

Untungnya, sekarang ini sangat baik untuk melakukan aplikasi tanpa RDBMS sama sekali. Sebagian besar tugas tidak membutuhkannya, atau tidak dapat dipetakan secara memadai ke model relasional. Ada banyak opsi penyimpanan non-relasional yang tersedia.

— SK-logic

8

Ini meringkas pendapat saya juga. Ahli? Tidak. Pengetahuan? Iya nih.

— Wayne Molina

2

@ SK-logic, Apa jenis opsi yang Anda rasa membuat basis data relasional tidak relevan? Gudang data terlalu khusus untuk analitik sehingga tidak berguna dalam sistem transaksional. Dan jangan mulai saya tentang segala sesuatu yang salah dengan OODBMS.

— maple_shaft

1

@maple_shaft, ada banyak solusi penyimpanan khusus yang berorientasi domain. RDBMS mencoba menjadi generik, dan gagal dalam hal itu. Dalam beberapa kasus bahkan DBMS hirarki kuno jauh lebih baik daripada relasional.

— SK-logic

6

Tidak semua perangkat lunak desktop menggunakan basis data, jadi berhati-hatilah ketika Anda mengatakan itu terjadi setiap saat.

— Adam Lear

18

Ada beberapa bidang keahlian (embedded system misalnya) di mana pengetahuan basis data tidak diperlukan. Tetapi sebagian besar aplikasi bisnis menggunakan semacam database dan jika Anda tidak benar-benar memahami cara menggunakannya dengan benar, Anda dapat membuat kekacauan kinerja yang sangat sulit untuk diperbaiki. Database refactoring dapat menjadi proses yang kompleks dan sulit dan banyak tempat memilih untuk tidak memperbaiki masalah struktural karena kesulitan itu dan hanya menggali diri mereka lebih dalam ke dalam lubang. Jika Anda memiliki pengetahuan basis data, desain jauh lebih mudah dan jauh lebih mungkin untuk bekerja dengan baik seiring waktu.

ORM bukanlah pengganti untuk mendapatkan pengetahuan basis data. Siapa pun yang menggunakannya tanpa mengetahui dasar-dasar kueri dan desain basis data pasti akan memiliki database yang berkinerja buruk, yang dirancang dengan buruk yang akan memengaruhi kemampuan aplikasi Anda untuk menangani beban dalam jangka panjang. ORM di tangan seseorang yang tahu apa yang dia lakukan baik-baik saja; di tangan orang-orang yang tidak dapat diganggu untuk belajar tentang database, mereka biasanya merupakan bencana.

Jika saya memiliki proyek dengan backend database, spesialis basis data akan menjadi pengembang kedua yang akan saya sewa (setelah pengembang aplikasi awal). Database pada umumnya tidak membuang-buang, bahwa data akan tetap ada di dekat dengan bentuk yang sama 20 tahun kemudian, membayar untuk memiliki keahlian dalam tahap awal.

Proyek sering mendapat masalah karena mereka tidak mempekerjakan orang-orang ini sampai database memiliki 100.000.000 catatan dan berjalan lambat. Atau mereka menyalahkan alat karena buruk (tidak ada SQL Server tidak lambat jika Anda mendesain dengan benar) bukan ketidakmampuan desain mereka.

— HLGEM
sumber

4

+1 untuk menyebutkan bahwa keberadaan ORM tidak menggantikan kebutuhan untuk mengetahui SQL (atau faktor yang mendasari tipe db apa pun yang Anda gunakan).

— RHSeeger

4

+1 dan saya berharap saya bisa memberi Anda 100 lebih! Saya tahu hubungan itu! = Sebab tetapi lebih dari jelas bagi saya bahwa pengembang aplikasi paling efektif yang pernah saya kerjakan memiliki pemahaman menyeluruh tentang cara menulis kueri SELECT standar. Saya harus bisa memberikan pengembang data model yang baik dan "pertanyaan" tentang data dan orang itu akhirnya harus bisa menulis permintaan yang "menjawab" pertanyaan saya.

— maple_shaft

1

+1, sepenuhnya setuju. Saya tidak membeli penjelasan bahwa 'kami menggunakan ORM' atau 'kami memiliki programmer khusus untuk itu'. Jika seseorang benar-benar berpengalaman , mereka akan mengisi peran pengembang db pada satu titik. Itulah pengalaman itu.

— GrandmasterB

15

Jawaban yang benar secara politis: Itu tergantung. Pengetahuan SQL tidak memiliki nilai apa pun jika pengembang tidak pernah bekerja dengan basis data relasional (dan pada hari ini dan usia aplikasi NoSQL, itu sebenarnya sangat mungkin).

Kedua, ketika ada DBA atau penulis kueri penuh waktu (apa pun judulnya), maka pemahaman juga kurang penting.

Ini hanya sangat penting jika pengembang perlu menjadi jack-of-all-trade dan ada persyaratan dalam proyek-proyeknya untuk menggunakan database relasional (misalnya dalam aplikasi web kuno atau terhubung dengan database yang ada)

Pendapat pribadi saya: Tidak. Pengembang perangkat lunak yang berpengalaman harus dapat mempelajari keterampilan baru (seperti SQL) jika dan ketika diperlukan, bukan 'secara default'. Fleksibilitas dan kemampuan untuk belajar dan memahami adalah, imho, yang membedakan pengembang yang baik dari yang baik. Aturan 'palu emas' juga berlaku - jika Anda memiliki pengembang dengan pengetahuan SQL yang luas, sangat mungkin pengembang ini akan mengeluarkan alat yang paling dikenalnya - basis data relasional - untuk mencoba menyelesaikan setiap masalah, sementara itu tidak harus memiliki menjadi solusi terbaik. Tentu saja, ini juga berlaku untuk pendukung NoSQL,;).

Memilih alat yang tepat untuk pekerjaan yang tepat adalah apa yang harus diketahui oleh programmer berpengalaman.

— Cthulhu
sumber

Database NoSQL tidak memproses lebih banyak data, atau lebih cepat, dari database relasional. Saya tidak tahu dari mana Anda mendengarnya, tapi itu salah , sangat berbahaya .

— Aaronaught

@Aaronaught - Diedit, terima kasih atas pimpinan asumsi prematur saya, :).

— Cthulhu

7

Lihat pengantar wikipedia ini untuk Pemrograman Komputer:

Pemrograman komputer (sering disingkat pemrograman atau pengkodean) adalah proses merancang, menulis, menguji, debugging / troubleshooting, dan memelihara kode sumber program komputer. Kode sumber ini ditulis dalam bahasa pemrograman. Tujuan pemrograman adalah untuk membuat program yang memperlihatkan perilaku tertentu yang diinginkan.

Query basis data memiliki bahasa mereka sendiri, mereka dapat dirancang, diuji, debbug, dan dipertahankan. Tujuan dari permintaan basis data adalah untuk memungkinkan Anda memperoleh informasi yang Anda butuhkan, seperti yang Anda butuhkan.

Jadi saya pikir itu pemrograman, pasti.

— guiman
sumber

7

Seorang insinyur perangkat lunak yang baik dengan latar belakang dalam aplikasi perusahaan dan bisnis (EDIT: khususnya dalam proyek-proyek yang menggunakan RDBMS) harus memiliki pengetahuan ahli dalam menulis permintaan basis data relasional dalam format standar. Selanjutnya mereka harus dapat memahami skema kompleks dan mengusulkan desain skema setidaknya kompleksitas sedang.

Desain skema yang sangat canggih atau rumit harus menjadi ranah pemodel data atau arsitek fungsional.

Ini tidak berarti bahwa Pemrogram Database tidak punya tempat juga. Prosedur tersimpan yang kompleks, permintaan dan arsitektur perangkat lunak tingkat dan basis data yang kompleks dan efisien yang berfokus pada alat unik dan penawaran dari vendor basis data tunggal (mis. Oracle, MySQL, SQLServer, dll ...) sebaiknya dibiarkan jika mungkin dengan perangkat lunak profesional insinyur yang memiliki pengalaman dengan penawaran khusus yang sangat khusus dan rumit ini.

Namun, sebagian besar sistem bisnis dan perusahaan menurut saya tidak membenarkan perlunya pemodel data dan pemrogram basis data khusus, tetapi saya telah mengerjakan proyek-proyek seperti itu sebelumnya. GREATLY mendapat manfaat dari pengetahuan dan keahlian yang dibawa orang-orang ini ke meja.

— maple_shaft
sumber

2

-1: sangat tidak setuju bahwa seorang insinyur perangkat lunak "baik" harus menjadi ahli dalam permintaan basis data relasional.

— John Saunders

3

Apakah Anda masih tidak setuju jika saya mengatakan bahwa insinyur perangkat lunak aplikasi ENTERPRISE atau BISNIS yang baik (sebagai lawan dari sistem tertanam, dll ...) dan jika saya mengatakan bahwa orang ini harus menjadi ahli di kueri basis data relasional STANDARD (tanpa vendor celana mewah) spesifik seperti pertanyaan analitis dan sejenisnya)? Pemahaman menyeluruh tentang pernyataan SQL SELECT, semua jenis gabungan, serikat pekerja, persimpangan dan penggabungan, tampilan sebaris, kondisi, urutan, dan kumpulan hasil pengelompokan harus dipahami secara menyeluruh dan banyak ditunjukkan oleh insinyur perangkat lunak APAPUN yang membawa label yang saya sebutkan di atas.

— maple_shaft

4

Meh Saya bekerja di perusahaan perangkat lunak besar dan kami tidak berurusan dengan RDBMS apa pun. Pekerjaan terakhir saya mengembangkan perangkat lunak desktop juga tidak memerlukan SQL. Saya tidak yakin bagaimana Anda mendefinisikan aplikasi perusahaan dan bisnis, tetapi bagi saya tampaknya pandangan Anda tentang hal-hal agak sempit.

— Adam Lear

2

Saya mendukung apa yang saya katakan. Secara teoritis jika aplikasi ini berjenjang dan diprogram dengan baik maka tidak perlu namun dalam seluruh pengalaman profesional saya tim saya dan saya akan DROWNED jika kami bukan ahli di SQL, bahkan ketika kami memiliki tim khusus untuk desain dan pengembangan RDBMS. Mungkin saya kuno atau hanya memiliki nasib buruk dalam karier saya?

— maple_shaft

3

@maple_shaft Ya, bukan karena aplikasi yang saya kerjakan sudah cukup tersusun. Itu karena mereka tidak menggunakan RDBMS apa pun, titik. Bidang yang berbeda, kurasa. Intinya adalah, Anda tidak bisa mengatakan bahwa setiap pengembang bisnis / perusahaan harus pandai SQL. Itu tidak benar. Jadilah ahli dalam hal itu jika Anda menggunakannya. Jangan terlalu khawatir jika Anda tidak sampai Anda membutuhkannya, seperti dengan bahasa atau teknologi lainnya.

— Adam Lear

6

Orang lain telah menjawab pertanyaan Anda tentang permintaan basis data.

Desain basis data adalah jenis desain tertentu. Ini tidak sulit untuk dipelajari, tetapi perancang basis data tipikal tidak mendapatkan banyak kesempatan untuk mendesain basis data.

Tempat saya bekerja sekarang memiliki desain database yang sama dengan yang ada pada tahun 1970. Kami telah memindahkan database dari IDMS ke DB2, tapi itu desain database jaringan yang sama. Saya memiliki kesempatan untuk membuat 5 tabel DB2 baru dalam 9 tahun saya telah bekerja di sini.

Saya menduga bahwa ada sangat sedikit tempat kerja dengan perancang basis data khusus. Jadi, saya menyimpulkan bahwa desain basis data dianggap sebagai bagian dari daftar analis senior.

— Gilbert Le Blanc
sumber

5

Saya terus terang kagum bahwa begitu banyak dari kita berpikir bahwa setiap pengembangan berkisar pada database, dan database SQL pada saat itu.

Yang lain telah menyebutkan banyak cara di mana kita dapat menghindari seluk-beluk SQL dalam pekerjaan kita, bahkan ketika kita bekerja (secara tidak langsung) dengan database, tetapi bagaimana dengan semua pengembang yang menulis firmware untuk 101 produk listrik yang kita masing-masing memiliki? Bagaimana dengan orang-orang yang berspesialisasi dalam pemantauan waktu nyata?

Saya akan menyarankan bahwa sebagian besar pengembang saat ini akan memiliki keterampilan SQL ke tingkat yang berbeda-beda, tetapi masih jauh dari menjadi barometer kemampuan mereka.

— cjmUK
sumber

5

Saya pikir Anda melebih-lebihkan pentingnya database dalam perangkat lunak.

Banyak kelas aplikasi tidak berpusat pada database.

Apakah kita memerlukan DBMS di pengolah kata dan editor gambar sekarang? Bagaimana dengan pengenalan suara dan sistem visi komputer yang mengandung banyak pertanyaan basis data?

Dan bagaimana dengan editor video linear dan mesin fisik video game?

— Alex Jasmin
sumber

5

Saya berharap pengembang generalis memiliki setidaknya kesadaran tentang teknologi basis data (relasional atau lainnya) dan dapat mendiskusikan pro dan kontra penggunaannya. Kalau tidak, aku takut yang mereka tahu bagaimana melakukannya adalah memasukkan data ke file datar.

— Barry Brown
sumber

4

Saya tidak berpikir menulis query harus menjadi persyaratan inti untuk programmer. Karena itu, saya percaya bahwa seorang programmer yang dapat menulis pertanyaan dan mendesain database akan lebih berharga bagi suatu organisasi.

Namun, jika pemrogram ini hanya dapat menulis kueri jenis "select * from tblxxxx", saya tidak akan menganggap pemrogram ini ahli. Demikian juga, jika database yang dirancang oleh programmer ini menempatkan hubungan satu-ke-banyak ke dalam satu tabel, bukan dua tabel maka saya tidak akan menganggap programmer ini sebagai ahli.

Inilah cara saya menjelaskan hal ini kepada orang-orang non IT. Para profesional TI berspesialisasi dalam bidang-bidang tertentu yang mirip dengan bagaimana tukang kayu, tukang listrik, dan tukang pipa mengkhususkan diri dalam bidang-bidang yang disegani di sana. Mereka cenderung tumpang tindih beberapa keterampilan tetapi tidak ahli di semua bidang. Seorang tukang listrik dapat melakukan tugas-tugas pertukangan sederhana dengan percaya diri tetapi tidak akan menjadi pertanda baik mencoba untuk mengatasi struktur yang kompleks.

Demikian juga, seorang programmer dapat dan harus tahu bagaimana menulis atau memanipulasi pertanyaan sederhana dan desain database tetapi tidak diharapkan untuk merancang struktur data yang kompleks.

— Michael Riley - AKA Gunny
sumber

3

Melihat-lihat di departemen kami, itu tergantung:

Kami pengembang desktop / web / server . Paling tidak diharuskan untuk menulis laporan dasar hingga tingkat lanjut tergantung pada spesialisasi mereka. Untuk optimasi, kami memiliki beberapa admin DB khusus.
Programmer tertanam kami . Cukup banyak yang tidak pernah melewati "select * from mytable". Namun, itu juga berubah dalam beberapa bulan terakhir ini dengan diperkenalkannya sqllite ke proyek mereka.

— Carra
sumber