@OneToMany izohi foydalimi?

Hayvonot loyihasida bu izohni ishlatish ajoyib ish bo'lib ko'rinadi, men xo'jayinman, ikkita xodimim bor va hokazo. Lekin haqiqiy miqyosdagi loyihalarda siz 100.000 chaqiriq yoki 1.000.000 fuqarosi bo'lgan shahar bilan bog'liq bo'lgan Buxgalteriya yili bilan yakunlanadi va sodda qilib ko'ring ularning barchasini ArrayList orqali olish uchun OutOfMemory xatolariga olib keladi.

Yaxshi yondashuv bunday munosabatlarni aniqlamaslikdir (lekin @ManyToOne) va bu natijalarni ular bilan xohlagan narsani bajarish uchun yozib olish.

Ya'ni, katta ma'lumotlar bazasi modeli bilan shug'ullanadigan kuzatuvchi nusxasi bormi yoki o'xshashmi? Xotirani boshqarish uchun foydalanishingiz mumkin bo'lgan har qanday konfiguratsiya?

4
Men hozirda kutish turini yoki boshqa biron-bir ramka, yoki hatto aniq SQL ishlatmasligingizdan qat'iy nazar, bunday ma'lumotlar bazasini so'rashni va aloqalarni barchasi ga kiritishingizni juda qiyin deb hisoblayman. Yoki so'rov uchun "Men bu shaharni va uning barcha fuqarolarini istayman" shaklida ishlatishingiz mumkinmi?
qo'shib qo'ydi muallif Kayaman, manba

8 javoblar

Aytaylik, ma'lum bir shahar uchun barcha fuqarolar ma'lumotlarini ko'rsatadigan arizangiz mavjud. Ushbu shaharda 1,000,000 fuqaro bor, shuning uchun foydalanuvchi interfeysi bo'yicha ushbu qatorlarni ko'rsatishni xohlaysiz.

Sizningcha, bu ma'lumotni darhol ko'rsatish mantiqiy emasmi yoki sizda rasmiyatchilik kerak deb o'ylaysizmi? Aytmoqchimanki, ikkinchisiga o'xshaydi, chunki hech kim UIda 1 million yozuvni o'qiy olmaydi.

Biror narsa taklif qilish uchun, agar sizda bunday ma'lumot mavjud bo'lsa, UIda ma'lumotni ko'rsatish uchun tashkilotlardan foydalanmang. O'zingiz ko'rsatadigan aniq ma'lumotlarni o'z ichiga olgan projektoriyalardan foydalaning +, shuningdek, sahifani osonlik bilan kiritishingiz mumkin.

Prognozlarni aniqlash usullari mavjud, eng osoni Bahor ma'lumotlari JPA xususiyati asosan interfeyslarni belgilaydi.

Albatta, sizda barcha fuqarolarni ish bilan ta'minlash kerak bo'lgan ishingiz bor bo'lsa, unda hamma narsani birdaniga olib keling, aksincha, bir partiyaning ijro etilishi yaxshi emas. Ma'lumotlaringizni alohida qismlarga bo'linib, keyin ushbu qismlarga murojaat qiling. Bunday hollarda, prognozlarni ishlatish ham yaxshi.

1
qo'shib qo'ydi

Aytaylik, ma'lum bir shahar uchun barcha fuqarolar ma'lumotlarini ko'rsatadigan arizangiz mavjud. Ushbu shaharda 1,000,000 fuqaro bor, shuning uchun foydalanuvchi interfeysi bo'yicha ushbu qatorlarni ko'rsatishni xohlaysiz.

Sizningcha, bu ma'lumotni darhol ko'rsatish mantiqiy emasmi yoki sizda rasmiyatchilik kerak deb o'ylaysizmi? Aytmoqchimanki, ikkinchisiga o'xshaydi, chunki hech kim UIda 1 million yozuvni o'qiy olmaydi.

Biror narsa taklif qilish uchun, agar sizda bunday ma'lumot mavjud bo'lsa, UIda ma'lumotni ko'rsatish uchun tashkilotlardan foydalanmang. O'zingiz ko'rsatadigan aniq ma'lumotlarni o'z ichiga olgan projektoriyalardan foydalaning +, shuningdek, sahifani osonlik bilan kiritishingiz mumkin.

Prognozlarni aniqlash usullari mavjud, eng osoni Bahor ma'lumotlari JPA xususiyati asosan interfeyslarni belgilaydi.

Albatta, sizda barcha fuqarolarni ish bilan ta'minlash kerak bo'lgan ishingiz bor bo'lsa, unda hamma narsani birdaniga olib keling, aksincha, bir partiyaning ijro etilishi yaxshi emas. Ma'lumotlaringizni alohida qismlarga bo'linib, keyin ushbu qismlarga murojaat qiling. Bunday hollarda, prognozlarni ishlatish ham yaxshi.

1
qo'shib qo'ydi

Xo'sh, bu dastur arxitekturasi masalasidir. Men o'z shaharlari orqali 1 million foydalanuvchilarni sotib olishning biznes qiymatini tasavvur qila olmayman, lekin men o'z egasi tomonidan foydalanuvchi yoki uy hayvonlari tomonidan shaharni olish kerak bo'lgan vaziyatni tasavvur qila olaman.

Shunday qilib, @ManyToOne uning natijalarini tushunish uchun ORM ishlatilgunga qadar patentsiz emas.

Ishlab chiquvchi yoki dasturiyalik me'mor sifatida siz domeningizning barchasini yaxshi bilishingiz kerak, va siz echimning yaxshi yoki yo'qligini bilishingiz kerak.

0
qo'shib qo'ydi

Xo'sh, bu dastur arxitekturasi masalasidir. Men o'z shaharlari orqali 1 million foydalanuvchilarni sotib olishning biznes qiymatini tasavvur qila olmayman, lekin men o'z egasi tomonidan foydalanuvchi yoki uy hayvonlari tomonidan shaharni olish kerak bo'lgan vaziyatni tasavvur qila olaman.

Shunday qilib, @ManyToOne uning natijalarini tushunish uchun ORM ishlatilgunga qadar patentsiz emas.

Ishlab chiquvchi yoki dasturiyalik me'mor sifatida siz domeningizning barchasini yaxshi bilishingiz kerak, va siz echimning yaxshi yoki yo'qligini bilishingiz kerak.

0
qo'shib qo'ydi

Boshqa javoblar allaqachon tushuntirilgandek, bunday o'ta holatlarda to'liq ishlaydigan @OneToMany assotsiatsiyasiga ega bo'lish yomon tushunchadir.

Biroq, bunday birlashma hali ham foydali bo'lishi mumkin bo'lgan holatda JPQL/HQL so'rovlari mavjud, chunki siz ota-onadan navigatsiya usulidan foydalana olasiz. To'plamga kirishga ishonch hosil qilish uchun, siz faqatgina to'plamning maxsus maydonchasida topmoqchiman va uni qabul qiluvchi va setterni ko'rsatmasdan etkazishingiz mumkin (va shirkatni dangasa qoldiring, albatta).

0
qo'shib qo'ydi

Boshqa javoblar allaqachon tushuntirilgandek, bunday o'ta holatlarda to'liq ishlaydigan @OneToMany assotsiatsiyasiga ega bo'lish yomon tushunchadir.

Biroq, bunday birlashma hali ham foydali bo'lishi mumkin bo'lgan holatda JPQL/HQL so'rovlari mavjud, chunki siz ota-onadan navigatsiya usulidan foydalana olasiz. To'plamga kirishga ishonch hosil qilish uchun, siz faqatgina to'plamning maxsus maydonchasida topmoqchiman va uni qabul qiluvchi va setterni ko'rsatmasdan etkazishingiz mumkin (va shirkatni dangasa qoldiring, albatta).

0
qo'shib qo'ydi

Boshqa javoblar allaqachon tushuntirilgandek, bunday o'ta holatlarda to'liq ishlaydigan @OneToMany assotsiatsiyasiga ega bo'lish yomon tushunchadir.

Biroq, bunday birlashma hali ham foydali bo'lishi mumkin bo'lgan holatda JPQL/HQL so'rovlari mavjud, chunki siz ota-onadan navigatsiya usulidan foydalana olasiz. To'plamga kirishga ishonch hosil qilish uchun, siz faqatgina to'plamning maxsus maydonchasida topmoqchiman va uni qabul qiluvchi va setterni ko'rsatmasdan etkazishingiz mumkin (va shirkatni dangasa qoldiring, albatta).

0
qo'shib qo'ydi

Ba'zi OneToMany munosabatlarida mos keladigan narsalar miqdori juda katta bo'lishi mumkin, ammo bu haqiqiy emas, aksariyat real hayot misoli mavjud. Agar Scrum Team a'zolari bilan Scrum Team ob'ektini tuzadigan bo'lsangiz, bu miqdor 3-9 ta ob'ektni tashkil etadi. Bu juda oz va OneToMany juda foydali.

Lekin sizning fikringiz to'g'ri: agar juda ko'p ma'lumot bo'lsa, hech bo'lmasa dangasa o'rnatilgan bo'lishi kerak va hatto yozuvlar miqdori juda katta bo'lishi mumkin. Agar shunday bo'lsa, Men OneToMany hech qanday qulay emasligini tasavvur qilaman. Bu holatda men "Spring Data" ga murojaat qilaman, sahifalarda juda katta ro'yxatni beradigan so'rovlar uslubiga ega bo'laman. Keyin, men UniToMany-ni o'chirib tashlayman, chunki men undan hech qachon foydalanmayman.

Ba'zi bir yon eslatma: Men har doim boshqa tomonni qilaman: ManyToOne, shuning uchun mappedBy foydalanishi mumkin va ma'lumotlar bazasi o'rtasida yangi jadval o'rniga xorijiy kalit bilan yaxshi jadvallarni yaratishim mumkin. Bu ko'pincha ishlash bilan bir oz yordam beradi va qanday qilib endi siz bir qo'ng'iroqda bir nechta narsalarni yuklashingiz mumkinligini his qildim. Ammo ... agar yuklarni yuklab olish uchun juda ko'p yozuvlar bo'lsa, bu xavfli hududga o'tishni xohlamaysiz, shuning uchun men yana o'sha OneToManyni olib tashlayman.

0
qo'shib qo'ydi