AppMaster veritabanıyla çalışmak için kapsamlı yetenekler sunar. Örneğin Arama bloğunu kullanarak gerekli verileri bulabilir, ilgili tabloları ona ekleyebilir, doğru sıraya göre sıralayabilirsiniz vb. Ancak bazı durumlarda bu yeterli olmayabilir ve ardından SQL Exec bloğu gelir. kurtarma. SQL'in tüm gücünü kullanarak herhangi bir veritabanı sorgusunu çalıştırmanıza olanak tanır.

Kitap kataloğunu içeren bir veritabanı örneğini kullanarak bloğun çalışmasını ele alalım.

Database structure

Biraz hazırlık çalışması yapalım. En basit haliyle, isteklerin gönderilmesine ve sonuçlarının alınmasına izin verecek bir iş süreci oluşturmak gerekir.

Business process

Ayrıca bu iş sürecine erişmenizi sağlayacak bir uç nokta oluşturmanız gerekecektir.

Endpoint

İlk aşamada bu yeterli olmalıdır. Uygulamanızı yayınlayabilir ve test etmeye geçebilirsiniz. Bunun için yayınlanırken otomatik olarak oluşturulan Swagger'ı kullanmak oldukça uygundur.

Veritabanından tüm kitapları istemesi gereken basit bir sorgu kullanıyoruz.

public.book'tan * SEÇİN

Lütfen tablonun kendisinde (veritabanı düzenleyicisinde oluşturulan diğer tüm tablolar gibi) şemayı belirten bir önek bulunduğunu unutmayın - public.

SQL Request

İsteğin başarıyla tamamlandığını ve sonucun alındığını doğrulayabilirsiniz.

SQL Response

Ancak sorun şu ki, cevabı bu biçimde algılamak çok zor. Olası bir çözüm, isteği biraz değiştirmek ve içinde yalnızca gerekli alanları (örneğin, kitabın başlığı ve sayfa sayısı) bırakmaktır. Ayrıca bir sınır koymak, veritabanındaki tüm kitapları istememek, kendinizi on kitapla sınırlamak mantıklı olacaktır.

public.book'tan ad ve sayfaları SEÇİN SINIR 10

SQL Response

Çok daha iyi ama yine de gerçek kullanıma uygun değil. Sonuçta, bir iş sürecinde yalnızca bir talep almanız değil, aynı zamanda bunun sonucuyla ilgili bir şeyler yapmanız da gerekir. Bunun için sonucun metin halinde olması yeterli değildir; daha sonra kullanıma uygun bir modele dönüştürmeniz gerekiyor.

Bunu yapmak için iş sürecine geri dönelim ve onu biraz iyileştirelim. Son blokta yeni bir değişken ekleyeceğiz - bir dizi kitap modeli.

Book Variable

Ayrıca istek sonucunda alınan JSON'u modele dönüştürecek bir bloğa da ihtiyacınız olacak. JSON'u modele göre seri durumdan çıkarın.

Updated Business process

Önceki isteğimizi tekrarlayalım ve sonucun hem görsel algı hem de BP'de daha sonraki kullanım için çok daha uygun hale geldiğinden emin olalım.

Updated SQL Response

Artık daha karmaşık mantığa geçebiliriz. Aşağıdakileri sağlayan bir iş süreci oluşturalım:

  • Giriş olarak kitabın başlığını alır.
  • Hangi kategoriye (türe) ait olduğunu belirler.
  • Sonuç olarak aynı kategoriden rastgele 3 kitap döndürür (bu durumda istekteki kitap bunların arasında olmamalıdır)

Bunu yapmak için, standart blokları kullanarak aramayı ve SQL sorgularının kullanımını birleştiren yeni bir iş süreci oluşturacağız.

İlk blok, bir kitabı başlığına göre bulmak ve ayrıca hangi kategorilere ait olduğunu belirlemektir. Bunu yapmak için arama bloğunu aşağıdaki parametrelerle kullanıyoruz:

  • _With = Kategoriler - sorgu sonucu, kitabın kendisine ek olarak ilgili kategori tablosundan da bilgi gerektirir.
  • _Limit = 1 - yalnızca bir kitabın bulunması gerekiyor.
  • _Ilike = False - ad istenen adla tam olarak eşleşmelidir.
  • Ad - Başlat bloğundan aktarılan kitap başlığının dizini.

Dizi Elemanı bloğunu 0 indeksiyle kullanarak sonuçtan ilk (ve tek) kitabı alıyoruz.

Bir kitap aynı anda birkaç farklı kategoriye ait olabilir ve bu durumda bunlardan herhangi biri bize uyacaktır. Rastgele öğe bloğu kullanılarak rastgele seçilebilir

Bundan sonra gerekli tüm verilere sahibiz ve geriye kalan tek şey şu şekilde görünebilecek isteğin kendisini oluşturmaktır:

SEÇ * FROM public.book NEREDE id IN (SEÇ rel1_id FROM public.book_categorys_category_books_pivot WHERE kitap_kategorisi_kategori_books_pivot.rel2_id = X) VE id <> Y ORDER BY random() SINIR 3

Burada X, kitap kategorisinin kimliğidir ve Y, kitabın kendisinin kimliğidir.

Lütfen bu sorgunun bir alt sorgu içerdiğini unutmayın. İlk olarak,book_categorys_category_books_pivot tablosundan (iki tablo arasındaki ilişkiler hakkında bilgi depolamak için kullanılır), seçilen kategoriye karşılık gelen tüm kitap tanımlayıcıları bulunur. Bundan sonra, başlığı iş sürecine aktarılan kitap kimliği hariç, belirtilen aralıkla eşleşen rastgele 3 kitabı bulan bir sorgu yürütülür.

Proje veri tabanı yapısını daha detaylı incelemek için Deploy Plans ayarlarında Open DB butonunu kullanabilirsiniz.

Veritabanını düzenleyicide açmanıza ve verileri görüntüleme ve düzenlemeye doğrudan erişmenize olanak tanır. Ancak dikkatli olmalı ve editördeki veri yapısını değiştirmenin projenin daha fazla yayınlanmasını imkansız hale getireceği gerçeğini hesaba katmalısınız.

Bir iş süreci oluşturmaya geri dönelim. İsteğin derlenmesini tamamlamak ve bunu yapmak için kitap ve kategori kimliğini tamsayıdan dizeye dönüştürmek ve ayrıca Concat Strings (Çoklu) bloğunu kullanarak son isteği birleştirmek gerekir.

Son adım, sorguyu yürütmek, sonucu bir modele dönüştürmek ve sorgu sonucu olarak End bloğuna göndermektir.

no-code

Değişikliklerinizi kaydedebilir, bir uç nokta oluşturabilir, projenizi yayınlayabilir ve isteğin doğru şekilde çalıştığını doğrulayabilirsiniz. Bu durumda, diğer birçok bloğun yerini almak ve iş sürecinin yapısını basitleştirmek için karmaşık bileşik sorguya sahip bir SQL Exec bloğu kullanıldı.

SQL Exec bloğunun kullanımı veri alımıyla sınırlı değildir ve çok çeşitli senaryolarda kullanılabilir. Birkaç seçeneğe daha yakından bakalım.

  • Kimliği=X olan bir kitabın yorum sayısını sayma
    public.comment'TAN COUNT(id) SEÇİN WHERE kitap_id = X
  • Bir kitabın ortalama puanının, yorumlarda verilen tüm puanlar dikkate alınarak hesaplanması:
    public.comment'TAN AVG(oran) SEÇİN WHERE kitap_id = X
  • 2023'ten önce yazılan tüm yorumların silinmesi (örneğin, günlüğü hızlı bir şekilde temizlemek için kullanılabilir).
    DELETE * FROM public.comment WHERE created_at < '2023-01-01'

Sonuç olarak, güvenliği artırmak için SQL Exec bloğuna şema değişikliklerine yol açabilecek tehlikeli işlemlere yönelik bir filtre eklendiğini belirtmekte fayda var.

Uygulama AppMaster sunucularında barındırılıyorsa, TABLE|COLUMN|INDEX|CONSTRAINT|SEQUENCE|SCHEMA|DATABASE için CREATE/ALTER/DROP/TRUNCATE filtre tarafından devre dışı bırakılır. Şirket içi barındırma sırasında, varsayılan olarak tüm istekler kısıtlama olmaksızın kullanılabilir.

Was this article helpful?

AppMaster.io 101 Çarpışma Kursu

10 Modüller
2 haftalar

Nereden başlayacağınızdan emin değil misiniz? Yeni başlayanlar için hızlandırılmış kursumuzla başlayın ve AppMaster'ı A'dan Z'ye keşfedin.

Kursa Başlayın
Development it’s so easy with AppMaster!

Daha Fazla Yardıma mı ihtiyacınız var?

Herhangi bir sorunu uzmanlarımızın yardımıyla çözün. Zamandan tasarruf edin ve uygulamalarınızı oluşturmaya odaklanın.

headphones

İletişim desteği

Bize sorununuzu anlatın, size bir çözüm bulalım.

message

Topluluk Sohbeti

Soruları sohbetimizde diğer kullanıcılarla tartışın.

Topluluğa Katılın