Saqlangan muolajalardan qachon foydalanishim kerak?

Agar barcha biznes mantiqiy kodimga ega bo'lsam va Entity Frameworkdan foydalansam, qanday holatlarda (agar mavjud bo'lsa), ba'zi bir ish mantig'ini o'zida saqlab turiladigan amalda saqlashni o'rniga, ?

Ma'lum bo'lish kerakki, hozirgi sozlash (kodning biznes mantig'i) bilan emas, balki uning o'rniga emas. Savdo protseduralarida barcha biznes mantiqlariga ega bo'lishni istagan ko'plab savollar borligini ko'rdim, biroq shunga o'xshash savollarni ko'rib qoldim, ammo ish mantig'ining qolgan qismini saqlab qolish bilan birga, saqlangan tartiblarni ishlatish uchun juda ko'p narsalarni topa olmadim kodda.

Agar u farq qilsa, MSSQL va Entity Frameworkdan foydalanaman.


Buning oldidan o'zida saqlanadigan muolajalarni ishlatgan vaziyatlar:

  • Bir necha daqiqa davom etadigan murakkab hisoboti (bu veb-ilovadagi sahifa edi).
  • nimaga qaraganda ancha samarali (faqatgina sekundlarga ishlaydigan) SQL yozishim mumkinligini topdim
  • Veb-ilovaga dasturga befarq bo'lmagan boshqa ko'plab nozik ma'lumotlarni o'z ichiga olgan alohida ma'lumotlar bazasida bir nechta jadvallarni o'qish va yozish kerak edi. Hamma narsaga ruxsat berishning o'rniga, faqat zarur bo'lgan narsalarni o'zida mujassam etgan va faqat cheklangan ma'lumotlarni qaytarib beradigan o'zida saqlab turilgan usulni qo'lladim. Veb-ilovaga faqat shu saqlangan amaliyotga faqatgina biron-bir stolga va boshqalarga kirish imkoni berilmagan bo'lishi mumkin.

Men bu savolni oldindan ko'rib chiqqandim:

14
Ikkala holatingiz ham saqlangan tartiblarni yozish uchun juda yaxshi qonuniy sabablardir. nima uchun ular qonuniy deb so'rayapsizmi?
qo'shib qo'ydi muallif sgwill, manba
Siz o'zingiz uchun yaratilgan boshqa texnikalardan yaxshiroq muammoni hal qilganini aniqlaganingizda, siz istisno qilasiz va o'zingizni saqlab turadigan biror amalni yozasiz.
qo'shib qo'ydi muallif sgwill, manba
@RobertHarvey Men ularning qonuniy ekanligiga ishonch hosil qildim va boshqa stsenariylarni yoki nima uchun istisno qila olaman va kodni saqlab turish o'rniga saqlanadigan protsedurani yozish uchun sabablarni qidiryapman.
qo'shib qo'ydi muallif Jason Bristol, manba

6 javoblar

Siz allaqachon yaxshi natija bergan bir nechta stsenariyingiz bor.

Bu erda juda ko'p boshqa sabablar bor. EF chindan ham CRUD va juda to'g'ri oldinga hisobotda yaxshi. Ba'zan EF - bu ajoyib vosita emas. Saqlanadigan muolajalarni Entity Framework bilan birgalikda foydalanishni ko'rib chiqish uchun ba'zi boshqa sabablar (senaryolar) quyidagilarni o'z ichiga oladi:

  • Sizda EF funktsiyalaridan foydalangan holda osonlikcha tranzaktsiyaga o'ralmagan ko'plab jadvallarni o'z ichiga olgan murakkab ish birliklari mavjud.
  • Sizning ma'lumotlar bazasi EF bilan yaxshi o'ynaydi, chunki u deklarativ referentning yaxlitligini (tashqi kalit cheklovlari) foyda bermaydi. Bu odatda o'zingizni topish uchun yomon stsenariydir, biroq ba'zida ETL jarayonlari uchun ishlatiladigan ma'lumotlar bazalari kabi tegishli stsenariylar mavjud.
  • Server chekkalarini bog'langan serverlar bilan kesib o'tuvchi ma'lumotlar bilan ishlashingiz kerak.
  • Sizda yetarlicha ishlashni ta'minlash uchun "yalang'och metal" SQL zarur bo'lgan juda murakkab ma'lumotlar olish stsenariylari mavjud. Masalan, muayyan vaziyatda yaxshi ishlashi uchun so'rovlar ko'rsatmalariga muhtoj bo'lgan murakkab birlashmalar mavjud.
  • Sizning arizangizda jadvalda to'liq CRUD ruxsatnomalari mavjud emas, lekin sizning arizangiz serveringiz ishonadigan xavfsizlik kontekstida ishlashga ruxsat berilishi mumkin (masalan, foydalanuvchi identifikatoridan ko'ra dastur identifikatori). Bu DBA-larni saqlangan treninglar uchun jadvalga ruxsat berishini cheklashi mumkin, chunki u ularga kim nima qila olishi ustidan yanada aniqroq nazorat qiladi.

Ishonchim komilki, bundan tashqari yana ko'p narsalar mavjud. Har qanday holatda oldinga eng yaxshi yo'lni aniqlashning yo'li ba'zi bir umumiy ma'nolardan foydalanish va yuqori sifatli, osongina saqlanishi mumkin bo'lgan kodni yozish uchun asosiy maqsadga e'tibor qaratishdir. Ushbu natijani har bir holatda bergan vosita (lar) ni tanlang.

8
qo'shib qo'ydi
Joelga rahmat aytdim, sen o'ylamagan bir nechta boshqa senaryolar haqida gapirding.
qo'shib qo'ydi muallif Jason Bristol, manba

Bu erda uchta muammo bor deb o'ylayman.

  1. SQLdagi biznes mantiqi yomon. Tezroq individual tarzda ishlayotgan bo'lsa ham, u miqyosi yo'q.

  2. Tridentionally SPROCs har doim ma'lumotlardan foydalanish uchun ajralma qatlami sifatida ishlatilishi kerak. DBA dasturini iste'molchi dasturlarga ta'sir qilmasdan ish faoliyatini yoki boshqa ma'lumotlarga o'zgartirishlarni kiritish uchun yoqish.

  3. EF sprots bilan yaxshi o'ynamaydi.

  4. Ling dinamik so'rovlarini yaratib, "yaxshi" xususiyatlar va mahsuldorlikka yutuqlarini yo'qotasiz.

Shunday qilib, mening umumiy maslahatim bo'lishi kerak edi

  • Barcha SQL so'rovlari uchun SPROC-lardan foydalaning,

  • Ish mantig'ini yoki ulardagi har qanday turdagi looplarni qo'ymang,

  • EF foydalanmang.

4
qo'shib qo'ydi
@Ewan: Yo'q, hamma db qo'ng'iroqlari uchun emas. Faqat bajarilgan ishlash/maxsus SQL talab qiladiganlar. Faqat 20 foiz (odatda, bu 5 dan 10 foizgacha). "Barcha saqlangan tartiblar, har doim" eng yaxshi amaliyoti yo'q.
qo'shib qo'ydi muallif sgwill, manba
Bu yomon maslahat, umuman olganda. Saqlangan protseduralarni qo'lda kodlash orqali afzalliklarga ega bo'lgan va odatdagidek amalga oshiriladigan ma'lumotlarga kirish imkoniyatlari ko'p. Sprillni EF dan to'g'ridan-to'g'ri ishlatishingiz mumkin; aslida biron-bir sql so'rovini EF dan to'g'ridan-to'g'ri ishlating. Ayrim ish mantiqlari ma'lumotlar bazasi serverida yaxshiroq ishlaydi, shuning uchun siz u erda taqiqlanganligini qat'iyan ifodalamaysiz. Ob'ektli relaparast mappers 80% vosita; ular hech qachon ma'lumotlaringizni erkin foydalanish jarayonlarini to'liq o'zgartirmoqchi emas edi. O'zida saqlanadigan protseduralardan foydalanish uchun mo'ljallangan vositalaridan foydalaning: ORM yaxshi ishlamayotgan 20%.
qo'shib qo'ydi muallif sgwill, manba
EF siz uchun ob'ektni hali ham xaritada saqlaydi. Siz uni qanday qilib to'g'ri chaqirishingiz kerakligini bilishingiz kerak.
qo'shib qo'ydi muallif sgwill, manba
Men ko'ryapman. Ammo keyin # 1 nuqtasi faqat ikkita ishlash muammolari o'rtasida savdo-sotiq to'g'risida. Ammo, SQL echimining ishlashi uchun aniq bir yutuq bo'lsa, shuning uchun uni qanday asosda "yomon" deb hisoblash mumkinligini bilmayman.
qo'shib qo'ydi muallif mınxomaτ, manba
bu SQL may ning o'lchamlari tufayli yomon dizayn bo'lishi mumkin bo'lgan alohida stsenariyga misol. Ammo keyin ham aniq emas: bu kutilgan foydalanuvchilar soniga, ma'lumotlar bazasida tashqi hisoblashni bajarishning nisbatan xarajatlariga va boshqalarga bog'liq. Albatta, siz ba'zi hollarda to'g'ringiz to'g'ridir, men faqatgina bu universal qoidadir deb o'ylamayman.
qo'shib qo'ydi muallif mınxomaτ, manba
@robert faqat qaytgan kol nomlari mos keladigan bo'lsa, odatda xaritalashni ozgartirishingiz kerak bo'ladi
qo'shib qo'ydi muallif Ewan, manba
@robert oldindan qanday sql bayonotlari tweaking kerak bilmayman. Sprocs sizga ajralma qatlamini beradi, ammo ularni har bir narsa uchun ishlatishingiz kerak, agar kodni o'zgartirish kerak bo'lsa, SQL sichqoncha kerak bo'ladi
qo'shib qo'ydi muallif Ewan, manba
Db-serverda ishlaydigan barcha SQL-lar faqat qo'shimcha hisoblash qutilari o'rniga qo'shimcha db-lar bilan ishlay olishi mumkin.
qo'shib qo'ydi muallif Ewan, manba
Sizda hisob-kitoblarni amalga oshiradigan veb-brauzeringiz bor. Buni kod yoki sql-da qilishingiz mumkin. sql boshida bir hisob-kitobni boshdan kechirishni tezroq bajarishi kerak. Lekin, xizmat juda ko'p arzon va osongina ikkinchi, uchinchi, to'rtinchi .. qutisini veb-brauzerini ishlaydigan, lekin qattiq va qimmat ikkinchi bir replikatsiya bazasi
qo'shib qo'ydi muallif Ewan, manba
@ dan1111 Men faqat tajribamdan javob bera olaman, bu juda katta miqdordagi kodni sqldan tashqari scalablity
qo'shib qo'ydi muallif Ewan, manba
@robert qila olasiz, lekin shu bilan EF, ORM imtiyozlarini yo'qotasiz. Agar siz eng yaxshi amallarni bajarayotgan bo'lsangiz va barcha db qo'ng'iroqlari uchun sprots dan foydalansangiz. Siz EF dan foydalanmasligingiz ham mumkin
qo'shib qo'ydi muallif Ewan, manba
EF bilan sprots dan foydalansangiz @amy, siz odatda EF dan kutishingiz mumkin bo'lgan tabelalar va linq -> sql va hokazolarga avtomatik moslashtirish moslamalarini yo'qotasiz
qo'shib qo'ydi muallif Ewan, manba
Iltimos, 3-bandni aniqlab bera olasizmi? EFdan foydalanish LINQ ning dinamik so'rovlar ishlab chiqarishidan uzoqlashayotganini tasavvur qilasiz, lekin men EF va LINQdan foydalanaman, shuning uchun men biroz murakkabman. Sizning fikringizni noto'g'ri tushunib qildimmi?
qo'shib qo'ydi muallif Jason Bristol, manba

Ehtimol, mantiqan to'g'ri, savolni atrofga aylantirib, faqat faqat protseduralari saqlanishi mumkin bo'lgan narsalarni topish uchun nima qilishni istaysiz. Ehtimol, amaliyotlar saqlanib qoladigan holatlar mavjud.

Agar farq qilsa, MSSQL va Entity Frameworkdan foydalanaman.

EF haqidagi bilimim cheklangan, ammo men ko'ra oladigan bo'lsam, EF ( faqat ) har qanday boshqa kabi ORM; va baxtli ravishda raw SQL dan foydalanishi mumkin.

Agar ikkita asosiy fikrni qabul qilsam:

Bir necha daqiqa davom etadigan murakkab hisobot (bu veb-ilovadagi sahifa edi).

</body>

LINQ/EF was falling short, when doing a report. And as you noticed, was SQL way faster, than using an ORM. But speaks this in favour of stored procedures or only against using the ORM for everything?

Muammoingiz aniq SQL bilan hal qilindi. Agar bu so'rov saqlanib qolsa va sizning codebase-dagi versiya tekshiruvi sizning namunangizga muvofiq - kamida farq yo'q .

Veb-ilovaga ilovaga befarq bo'lmagan boshqa ko'plab nozik ma'lumotlarni o'z ichiga olgan alohida ma'lumotlar bazasida bir nechta jadvallarni o'qish va yozish kerak edi. Hamma narsaga ruxsat berishning o'rniga, faqat zarur bo'lgan narsalarni o'zida mujassam etgan va faqat cheklangan ma'lumotlarni qaytarib beradigan o'zida saqlab turilgan usulni qo'lladim. Veb-ilovaga faqat ushbu saqlangan amaliyotga faqatgina biron-bir stollarga va boshqalarga kirish imkoni berilmagan bo'lishi mumkin.

Bu erda ham bir xil narsa: oddiy aloqa liniyasi va UPDATE va muammoingiz tugadi. Bu muammo ORM bilan hatto bilan echilishi mumkin: oddiygina boshqa WBga qarashli veb-brauzerni ishlatadi va bir xil taqsimlash / izolyatsiya ga erishiladi.

Shunday qilib, bu erda hech narsa yo'q.

Ba'zi fikrlarga qaraganda, boshqalar:

Kompleks ish birliklaringiz bor, ehtimol ko'p jadvallarni o'z ichiga oladi, ular EF funktsiyalaridan foydalangan holda osonlikcha tranzaktsiyaga o'ralmagan bo'lishi mumkin.

Lekin SQL buni amalga oshirishi mumkin. Bu yerda sehrli yo'q.

Shaxsiy ma'lumotlar bazasi EF bilan yaxshi ishlamaydi

Shunga qaramay: tegishli bo'lsa ef dan foydalaning.

Aloqador serverlar bilan server chegaralarini kesib o'tuvchi ma'lumotlar bilan ishlashingiz kerak

Qanday qilib saqlangan tartiblar yordam berayotganini ko'rmayapman. Shuning uchun men ga qarang o'zida saqlab muolajalarni afzalliklari; lekin ehtimol, kimdir bunga qandaydir nur tushiradi.

To'g'ri ishlashni ta'minlash uchun "yalang'och metal" SQL zarur bo'lgan juda murakkab ma'lumotlar olish stsenariylari mavjud

Yana: " EF chegara ".

Sizning arizangizda jadvalda to'liq CRUD ruxsatnomalari mavjud emas, lekin sizning ilovangiz serveringiz ishonadigan xavfsizlik kontekstida ishlashga ruxsat berilishi mumkin

Xop. ehtimol bilan ketaman.

Shu paytgacha saqlanadigan protseduralar foydasiga faqat yarim nuqtasi kiritilgan.


Ehtimol, saqlanadigan protseduralardan foydalanganda gaplashadigan ijro etuvchi fikrlar bor.

1) So'rovlarni saqlash murakkablikni o'z ichiga olgan o'zida saqlab yuradigan amaldagi oddiy chaqiruvidan foydalidir. So'rovlar planeri so'rovni bilgani uchun, u "optimallashtirish" uchun osondir. Biroq, saqlanishlar hozirgi murakkab so'rovlar planeri _minimal.

Bundan tashqari, ad hoc so'rovlarini ishlatib, kam xarajat bo'lsa ham, ma'lumotlaringiz yaxshi tuzilgan va ehtiyotkorlik bilan indekslangan bo'lsa, ma'lumotlar bazasi faqat darboğaz ilovasidan foydalaning. Shunday qilib, kichik delta bo'lsa ham, boshqa omillar hisobga olinmaydi.

2) Shunday bo'lsa-da, kompleksi so'rog'ini JB-da saqlash uchun shubha ostiga olingan. Buni hisobga oladigan ikkita narsa bor:

a) murakkab so'rovlar har bir so'rov uchun eng ko'p vaqtni oshiradigan JB infratuzilmasidan keng foydalanishni ta'minlaydi. parallel qatoridagi qimmatli so'rovlarini ishga tushirib bo'lmaydi. Bu pro yoki contra saqlangan tartiblarni emas, balki kompleksi so'rovlariga javob bermaydi.

b) Agar so'rovlar vaqtni talab qiladigan bo'lsa, nima uchun o'zida saqlanadigan protseduraning kichik tezlikda g'oliblari bilan bezovtalanish kerak.

tl; dr

Hech narsa to'g'ridan-to'g'ri qarshi usullarini saqlaydi. Shunday qilib, saqlangan tartiblarni ishlatish sizni xursand qiladi.

Boshqa tomondan: mutlaqo gapiradigan pro deb nomlangan foydalanish holatlarini tasavvur qila olmadim.

Saqlangan muolajalarni qachondan foydalanishi kerak?

To'g'ri javob: istagan paytda . Ammo boshqa variantlar mavjud.

2
qo'shib qo'ydi

Texnik ehtiyojga ega bo'lish, eng yaxshi variant emas. Dasturchilar o'z vositalarini afzal ko'rishadi va odatda ular bilan muammolarini hal qilishda ko'proq moslashishadi. Mantiqni sprokka qo'yish istisno bo'ladi. Texnik qarzlar va kelajakdagi devlar istisno bilan ishlashga vaqt ajratish kerak. O'zingizning RDBMS-laringizda ishlashni kuchaytirishi mumkin, bu faqatgina bir ishorada yoki hatto endeksli ko'rinishdagi boshqa bir db ob'ektida amalga oshirishni osonlashtiradi.

Ma'lumotlar bazasidan ma'lumotlarni talab qiladigan paytlar bo'ladi va siz uni faqatgina dastur kodidan olisholmaysiz. Ko'pgina yirik kompaniya/korxona sharoitida biznesga bo'lgan talablar IT-bo'limining tushunchasidan oshib ketishi mumkin. Kompaniyalar sotib olinadi va sotiladi va dasturlari ular bilan birga keladi. Sizni yuqori darajada o'lchaydigan va chiroyli kodlangan ilovangizni yaratib bo'lmaydigan qilib tartibga soluvchi agentliklar va banklar sizni qiziqtirmaydi. Ular biznes uchun hayotni qiyinlashtirishi mumkin, shuning uchun uni bajarish kerak.

Uchinchi tomon dasturlari yoki hisobot yozish vositalari sizning kodingizga kirishga ruxsat bermagan holatlarga tushdim. On manba kodi, API mavjud emas, veb-interfeys va xizmatlar yo'q. Ulardagi yagona narsa faqat ma'lumotlar bazasi ob'ektlari bilan ishlaydigan o'z maxsus hisobot yozish vositasi: jadvallar, fikrlar, sprocs, foydalanuvchi belgilaydigan vazifalar va boshqalar.

Agar saqlangan tartiblarni yozishda juda yaxshi bo'lgan DBA bo'lsa, ba'zi hollarda bu ko'nikmalarni qo'llashingiz mumkin. Siz o'zingizning ma'lumotlaringizdan zaxirangizni ishga tushirishni xohlashingiz mumkin, chunki siz katta ma'lumot almashinuvini amalga oshirasiz, shuning uchun nima uchun dbadan foydalanasiz?

Ba'zi Ad-hoc so'rovlaringiz sizning ilovangizdagi barcha funksiyalarni olishingiz mumkin bo'lmaguncha, siz chop etishni osonlashtiradi. Biz buni yomon ko'ramiz. Biz orqaga o'giramiz, lekin namoyishlar davom etishi kerak.

0
qo'shib qo'ydi

Sizning shaxsiy ishingiz uchun korxona doirasidan foydalanganingiz sababli, korxona ruxsati talabni yoki tashvishni qondira olmasa, saqlangan tartiblarni qo'llash kerak.

Korxona doirasi yaxshi ish olib boradi va ishlash saqlangan protseduralar yordamida yaqin yoki teng bo'ladi. Siz sub'ektlar ramkasini tanladingiz, chunki siz SQL bilan xavotirlanmoqchi emassiz va framework siz uchun SQL yaratadi.

Biroq, korxona doirasi qisqartirilib, sizning ehtiyojlaringizni qondira olmasliklari mumkin. Bunday holatda, SQL qo'l bilan saqlangan yordan yoki parametrlangan so'rovlardan foydalangan holda yozadi va undan so'ng o'zida saqlanadigan yordan/SQL ifodasini to'g'ridan-to'g'ri chaqirish uchun shaxs ramkasidan foydalanadi.

Shunday qilib, ishlayotgan me'yor talabni qondira olmas ekan, men hech narsa o'zida saqlab turishga majbur qilmayman.

O'ylaymanki, eng yomon narsa, shaxsning ob'ektini ishlatishni tanlaydi va undan so'ng barcha saqlangan tartiblarni yozadi. Hozirda hech qanday qiymat kiritmagan qo'shimcha qatlam mavjud.

0
qo'shib qo'ydi
100% oxirgi xatboshiga rozi
qo'shib qo'ydi muallif Ewan, manba

Men har qanday biznes mantig'ini saqlangan tartibda joylashtirishga qattiq maslahat beraman. Biroq, u erda (ikkita yaxshi misol keltirgan) vaziyat bo'lishi mumkin, bu erda ma'lumotlarga kirish mantig'ini joylashtirish afzallik beriladi.

Umuman aytganda, agar siz SP-ni ishlatishni xohlasangiz, bu sizning ma'lumotlar modelingiz uning ehtiyojlariga mos kelmasligini ko'rsatuvchi belgi (kod hid).

Tahrirlash: Ishlab chiquvchilar biznes/ma'lumotlarga kirish mantig'i haqida so'raganda, men biznes mantig'i ma'lumotlarning qanday ishlashi va o'zaro aloqadorligi haqida ma'lumot beradi, ma'lumotga kirish mantiqlari ma'lumotlarning qanday saqlanishi va olinishi haqida.

Ko'rib uchun: Sizning domeningiz modelida "Shaxs" va "O'qituvchi" bo'lgan shaxslar ham bo'lishi mumkin. (Buning afzalligini aytmoqchi emasman, faqat bir misol). Bu relokatsion databaslarda bir, ikki yoki uchta jadval sifatida saqlanishi mumkin. Tanlash qanday xususiyatlarga ega bo'lishiga va o'qish/yozish ishlash talablariga bog'liq.

Biznes mantiqida bu narsalar qanday saqlanganligi muhim emas. (yoki hech qanday RDBda yashamaydi). Ma'lumotlarga kirish mantig'i ularning jismonan qanday saqlanganligi haqida.

Shunday qilib, dastlabki savolga nisbatan: Agar saqlanadigan protsedura ma'lumotni yanada samarali (yoki mustahkamroq) saqlash va olishni amalga oshiradigan bo'lsa, sizda bunday holat mavjud. O'zida saqlab turiladigan amaliyot faqat ma'lumotlarning qanday saqlanishidan qat'iy nazar joriy bo'lgan qoidani belgilash uchun bo'lsa, uni saqlang. Bu sizning kodingizni ma'lumotlar bazasiga yanada qattiq bog'langan qiladi.

0
qo'shib qo'ydi
Ularning maqsadi ma'lumotlarga kirish bo'lsa.
qo'shib qo'ydi muallif sgwill, manba
@AmyBarrett: Ba'zan siz Data Access katmanida maxsus usullarni yozasiz, shuning uchun har doim CRUD emas.
qo'shib qo'ydi muallif sgwill, manba
qo'shib qo'ydi muallif sgwill, manba
Ma'lumotlarni kirish mantig'i deylik, "pastki jadval qatori soni 5 dan kam bo'lgan barcha satrlarni qabul qilish" ish mantig'i "col x> 5 bo'lsa, keyin col y = katta mijoz"
qo'shib qo'ydi muallif Ewan, manba
Ishonchim komil emas, nima uchun pastga tushdim. Amys masalasi haqida tahrirlangan
qo'shib qo'ydi muallif BlueMoon93, manba
Izoh va misol uchun rahmat, men ushbu mantiqni biznes mantiqiga qo'ygan edim.
qo'shib qo'ydi muallif Jason Bristol, manba
@RobertHarvey Ushbu maxsus usullar ish mantiqiy qatlamiga tegishli emasmi?
qo'shib qo'ydi muallif Jason Bristol, manba
@RobertHarvey Aloqalar uchun rahmat. Ma'lumotlarga kirish qatlami ma'lumotlar kirish mantig'i bilan bir xilmi? Ma'lumotlar erkin foydalanish qatlami - oddiygina CRUD operatsiyalari bilan bog'liq haqiqiy mantiqqa o'xshamaydi.
qo'shib qo'ydi muallif Jason Bristol, manba
biznes mantig'ini va ma'lumotlarga kirishni mantiqini qanday qilib aniqlasa bo'ladi?
qo'shib qo'ydi muallif Jason Bristol, manba