Bagaimana saya tahu data saya bersifat relasional atau berorientasi objek?

16

Cukup baca baris ini-

Jika data Anda adalah objek di alam, maka gunakan penyimpanan objek ("NoSQL"). Mereka akan jauh lebih cepat daripada database relasional.

Jika data Anda bersifat relasional, overhead database relasional tidak sia-sia.

dari-

http://seldo.com/weblog/2011/06/15/orm_is_an_antipattern

Jadi, bagaimana saya tahu apakah data saya bersifat relasional atau berorientasi objek?

object-oriented database relational-database

— Gulshan
sumber

Ceritakan lebih lanjut tentang data Anda ...

— FrustratedWithFormsDesigner

7

@FrustratedWithFormsDesigner Saya pikir dia sedang mencari pedoman umum.

— C. Ross

Garis yang berbicara tentang "toko nilai-kunci yang akan memungkinkan Anda untuk memegang struktur data yang anggun dan mandiri dalam jumlah besar dan mengaksesnya dengan kecepatan kilat" tampaknya menggambarkan data "objek" yang harus digunakan di NoSQL - pada dasarnya kedengarannya seperti potongan data "mandiri" tanpa referensi atau hubungan dengan potongan data lain ... Saya tidak bisa memberikan contoh yang baik tentang ini karena itu bukan sesuatu yang biasa saya kerjakan (setidaknya tidak dalam konteks ini) .

— FrustratedWithFormsDesigner

Baru saja mendapat tautan ini. Semoga ada petunjuk untuk menjawab- highscalability.com/blog/2011/6/15/…

— Gulshan

16

Dengan risiko ditembak berkeping-keping, saya akan mencoba definisi bahasa Inggris yang sederhana.

"Sifat relasional" bagi saya diterjemahkan menjadi: semua item dari tipe tertentu memiliki atribut yang hampir sama, yang membuatnya cukup mudah untuk merancang tabel sederhana, tetapi semua item ke dalam tabel itu dan kemudian SQL untuk melakukan CRUD dan pengambilan. Selain itu, jika data Anda dapat dimodelkan sehingga semua item memiliki salah satu dari serangkaian jenis terbatas, Anda kemudian dapat menentukan struktur data relasional yang sesuai dengan serangkaian jenis ini.

"Sifat objek" diterjemahkan menjadi: Item dengan tipe yang mirip dapat memiliki beragam atribut, dan atribut ini bisa beragam, sifat dan jenisnya. Sangat sering hal ini dapat (dengan usaha yang cukup) diterjemahkan ke dalam model relasional, tetapi banyak tabel akan sangat jarang penduduknya dan Anda akan berakhir dengan bergabung dengan LEFT OUTER yang sangat tidak efisien, yang membuat kinerja database relasional menjadi lamban bila dibandingkan ke database NOSQL.

Saya harus mengatakan bahwa dari sudut pandang saya tidak ada garis tegas yang memisahkan keduanya. Anda mungkin dapat menemukan sejumlah contoh yang berada di antara dua ekstrem.

OK, jadi sekarang saya telah membuka diri untuk penembak jitu dari segala arah. Setiap komentar diterima. Mari kita lihat apakah kita dapat memperbaiki definisi ini bersama-sama.

— wolfgangsz
sumber

1

Sebenarnya sebagai seseorang yang awalnya mengejek kesederhanaan pertanyaan, saya harus mengatakan bravo untuk jawaban yang dimengerti dan berwawasan. Anda harus melihat ke dalam menulis buku.

— Philip

Bisakah kita meringkas ini menjadi "memiliki terlalu banyak LEFT OUTER BERGABUNG dalam desain relasional" atau tidak?

— Gulshan

Saya akan ragu untuk membuat penyederhanaan seperti itu. Itu salah satu gejalanya, tetapi bukan satu-satunya.

— wolfgangsz

Sedikit contoh, tolong?

— Gulshan

Katakanlah Anda menyimpan informasi tentang orang. Siapa pun dapat memiliki kombinasi atribut apa pun dari kumpulan 300. Semuanya dapat muncul beberapa kali atau tidak sama sekali. Beberapa dari mereka terdiri dari kombinasi atribut lainnya, yaitu mereka adalah himpunan. Dan sekarang Anda ingin mencari semua orang di mana atribut tertentu tidak ada atau tidak memiliki nilai tertentu. Itu adalah hal yang akan membuat pembangun query SQL normal Anda menjadi gila.

— wolfgangsz

5

Data keduanya.

(Sebenarnya itu tidak bisa menjadi objek di alam karena tidak memiliki perilaku, tetapi kami tidak akan melakukan nitpick).

Keputusan tentang penyimpanan data dalam basis data RDBMS atau NoSQL lebih tergantung pada bagaimana Anda bermaksud menggunakan data , daripada 'sifat' sebenarnya dari data itu sendiri.

Jika Anda bermaksud mendukung segala macam jalur navigasi ke data, maka Anda mungkin ingin menyimpan data dalam RDBMS karena Anda akan memiliki berbagai cara untuk mengakses dan menyajikan data. Anda membutuhkan database untuk melakukan banyak hal untuk Anda. Misalnya, data 'Pesanan' dapat diakses melalui pelanggan, tenaga penjualan, sku (item), tanggal, wilayah, dll.

Di sisi lain, jika Anda memiliki jalur navigasi minimal, Anda dapat menyimpan seluruh objek. Misalnya, 'Keranjang' yang hanya diakses oleh ujung depan web dan tidak disimpan lama atau dianalisis banyak, mungkin lebih cocok untuk toko NoSQL. Pengorbanan yang Anda lakukan dengan (nilai dokumen atau kunci) penyimpanan data NoSQL adalah bahwa Anda melakukannya tanpa hubungan di antara koleksi - jika Anda tidak membutuhkan hubungan tersebut (untuk jalur navigasi, permintaan atau laporan ad-hoc) dan mengurusnya di Anda aplikasi, maka Anda akan baik-baik saja.

Tentu saja, Anda dapat menyimpan data di keduanya karena alasan yang berbeda, tetapi itu memiliki kekurangannya sendiri.

— Simon Munro
sumber

2

Data bukan 'objek di alam' atau 'relasional di alam'. Setiap jenis data dapat direpresentasikan dalam model objek / struktur grafik relasional atau Apa yang sesuai tergantung pada bagaimana data akan digunakan oleh aplikasi. Seringkali Anda mungkin memiliki keduanya. Misalnya data yang digunakan di situs web dapat disimpan dalam database relasional, tetapi sesuai permintaan dimuat ke dalam struktur grafik yang kemudian di-cache di penyimpanan nilai kunci di memori.

Pernyataan bahwa objek menyimpan / NoSql akan lebih cepat daripada relasional untuk beberapa jenis data adalah salah. Yang penting lagi bagaimana aplikasi Anda menggunakan data, bukan bentuk data itu sendiri. Toko objek akan lebih cepat dalam memuat grafik objek yang disimpan sebagai satu unit, tetapi akan jauh lebih lambat di permintaan ad-hoc di banyak objek, atau memperbarui properti pada banyak objek.

— JacquesB
sumber

0

Saya pikir kunci dari artikel ini adalah:

"Likewise, sometimes the output will be a single object X, which is easy to represent. But sometimes the output will be a grid of aggregate data, or a single integer count"

Menurut saya penulis membuat poin yang baik bahwa jika kode Anda misalnya mendapatkan Jumlah pelanggan di Spanyol untuk sedikit logika, Anda tidak boleh mengisi daftar pelanggan dengan semua pelanggan di Spanyol dan kemudian menghitung objek pelanggan. (yang ORM mungkin mendorong Anda ke arah)

Jelas Anda tidak bisa mengatakan dari struktur data pelanggan itu sendiri apakah itu akan digunakan seperti itu. jadi saya pikir kita harus menafsirkan 'data' yang berarti 'Semua informasi yang digunakan oleh aplikasi Anda'. Jika ini termasuk hal-hal seperti agregat atau 'Semua X yang terkait dengan Y' maka 'data' Anda tidak cocok untuk pendekatan atom NoSql

— Ewan
sumber