RESTful API için SQL Veritabanı Yapısı

RESTful API oluşturuyorum. Veritabanı tablolarımı kaynaklarım etrafında tasarlamanın en iyi yoluna karar vermek için uğraşıyorum.

Başlangıçta, kaynak başına bir tablo gitmek için iyi bir yol olsa da, ama şimdi bunun gittiğiniz kaynak zincirinde aşağı katlanarak daha büyük tablolarla sonuçlanmasından endişe ediyorum.

Örneğin, üç kaynağım olduğunu düşünün - kullanıcılar, müşteriler, satışlar. Kullanıcılar API'ma abone, müşteriler kullanıcı müşterileridir ve satışlar her müşteri tarafından kullanıcı hesabına yapılan satın alımlardır.

Bir satış kaynağına aşağıdaki gibi erişilir

GET /users/{userID}/clients/{clientID}/sales/{salesID}

Bu nedenle, her biri 10 müşterisi olan 10 kullanıcı varsa ve her müşteri için 10 satış varsa, tablo boyutu gittikçe kaynak zincirinden daha da büyür.

SQL'in büyük tablolarla başa çıkabileceğinden oldukça eminim, ancak okuma ve yazma işlemlerinin nasıl yavaşlayacağından emin değilim. Yukarıdaki örnek belki bunu göstermez, ancak API'm gittikçe daha fazla yazacak ve gittiğimiz kaynak zincirini daha aşağıya okuyacaktır. Bu nedenle, veritabanımdaki en büyük tabloların daha küçük tablolardan daha fazla okunup yazılacağı senaryoya sahibim.

Sorguları çalıştırmadan önce tablolara katılmak da gerekecektir. Bunun nedeni, her kullanıcının aynı ada sahip bir istemciye sahip olmasına izin vermemdir. Yanlış istemci verilerinin alınmasını önlemek için, kullanıcı tablosu ve istemci tabloları {userID} ile birleştirilir. Bu satış için de geçerlidir. Büyük tablolara katılmak ve okuma ve yazma işleri yavaşlatıyor mu?

Veritabanı tablolarımı kaynaklarım etrafında tasarlamanın en iyi yoluna karar vermek için uğraşıyorum.

Yapma.

Göre senin API Tasarım RESTful Principes göre veritabanı tasarım, normalleştirme ilkelerine . Birinin diğerini etkilemesi gerekmez.

Veritabanınız bir SaleResourcetablo içermemeli, bir Sale(veya satın alma / sipariş) tablosu içermelidir . Bu tablo, bir Satış ve ilgili Kullanıcı ve Müşteri tablolarına yabancı anahtarları benzersiz şekilde tanımlayan bir birincil anahtar içerecektir.

REST api, tarafından tanımlanan kaynak için bir isteği GET /users/{userID}/clients/{clientID}/sales/{salesID}uygun veritabanı sorgusuna çevirir , satırı alır, bir Satış'ı temsil eden kaynağı oluşturur ve istemciye döndürür.

Şu anda dahili veritabanı tanımlayıcıları (UserID / ClientId / SalesID) gibi görünen öğelerin dış dünyaya gösterildiğini unutmayın. Sizin durumunuz için uygun olabilir, ancak genellikle <entity>IDRESTful API'sinde hissedilir.

İlişkisel veritabanları (dolayısıyla SQL), büyük tablodan bir (veya birkaç) satır bulmakta gerçekten iyidir. Dizinler bunun içindir. Ayrıca birleşimleri ele alma konusunda oldukça harikalar. Gerçekten bir sorunuz yok . Satırlar arasında temel olarak çok kiracılı bir veritabanı tasarımının nasıl yapılacağını soruyorsunuz. Daha fazla soru sormadan önce Çok Kiracılı Veri Mimarisini okumanızı tavsiye ederim . Kalıplardan birini seçin (ayrı veritabanı, paylaşılan veritabanı ayrı şemaları, paylaşılan veritabanı paylaşılan şeması) ve sonra ayrıntıları tartışmak istiyoruz. Şu anda sadece son modeli öngörüyorsunuz, ancak artıları ve eksileri dikkate almadınız. Oku.

Bir yan not olarak: user/{userID}URI'de ihtiyacınız yoktur . Kimlik doğrulama bilgilerinden kiracıyı (userID) biliyorsunuz.

Sadece burada söylenenlere eklemek için - gerçek API ile veritabanı katmanınız arasında bir arayüz oluşturmak isteyebilirsiniz. Önbellek ve özet tabloları eklemeyi kolaylaştırır ...