delphi4arab منتديات دلفي للعرب
فكرة تجزئة البيانات بعدة جداول - نسخة قابلة للطباعة

+- delphi4arab منتديات دلفي للعرب (https://delphi4arab.net/forum)
+-- قسم : منتديات دلفي للعرب التعليمية (https://delphi4arab.net/forum/forumdisplay.php?fid=3)
+--- قسم : دلفي للعرب - القسم العام (https://delphi4arab.net/forum/forumdisplay.php?fid=10)
+--- الموضوع : فكرة تجزئة البيانات بعدة جداول (/showthread.php?tid=4081)

الصفحات: 1 2


فكرة تجزئة البيانات بعدة جداول - CMT-10 - 08-04-2012

السلام عليكم

انا كنت ارغب في جعل العنوان ( اتحداكم تعملوها )
لاني جلست احسب هل بالامكان التعامل مع 8000 الاف فاتورة حيث لو ان كل واحد بها متوسط 5 سجلات فسيكون مجموع السجلات 40000 سجل .
اربعين الف سجل اذا اردت ان تجري عليهم عملية ما فستحتاج الى 20 ثانية تقريبا لتحصل على الناتج
فقلت غير معقول ان يكون المحل ينتج 8000 الاف فاتورة فلو ربح كل فاتورة متوسط مبيعها 5 دولارات فالمجموع 40000 دولار وهذا مستحيل بالنسبة الى هذه المحلات المتوسطة .
وقلت ان العدد المقبول ليكن 2000 فاتورة
ف سألت احد العملاء كم فاتورة تقريبا تخرج كل سنة بين مبيعات ومشتريات
ارسلت برسالة فغاب طويلا تم ارسل لي هذه الكلمة
500,000
نصف مليون فاتورة وانا كنت مفزوع من ثمانية الالاف فاتورة ماذا اعمل فيهم
نصف مليون مظروبة في 5 تعني 25000000 سجل
يعني بصراحة الراجل مخربط بالتاكيد
وقلت بعدها ما فيش الا حل واحد
اقسم قاعدة البيانات الى 12 جدول وكل شهر من المبيعات والمشتريات اضعه بجدول


فكرة تجزئة البيانات بعدة جداول - أبو معاذ - 08-04-2012

[INDENT]
وعليكم السلام ورحمة الله وبركاته ،
هذا يتعلق بطبيعة قاعدة البيانات المستعملة ، أنا استعمل قاعدة بيانات Interbase و بعض الزبائن يتجاوز عدد الفاتير عنده 10000 (عشرة آلاف) فاتورة و لا مشكلة لا في البحث و لا في التحديث.
[/INDENT]


فكرة تجزئة البيانات بعدة جداول - palunix - 08-04-2012

unprogramme كتب :[indent]
يتجاوز عدد الفاتير عنده 10000 (عشرة آلاف) فاتورة و لا مشكلة لا في البحث و لا في التحديث.[/indent]
حتي لو كانت اكسس تكفي لمثل هذه الحجم و بكفاءه ممتازه.


فكرة تجزئة البيانات بعدة جداول - هاوي دلفي - 09-04-2012

السلام عليكم
أنصحك باستخدام قاعدة البيانات Oracle ولا تهتتم أبداً لعدد السجلات الواجب البحث فيها أو التعامل معها


فكرة تجزئة البيانات بعدة جداول - shagrouni - 09-04-2012

السلام عليكم

قل لنا ما نوع قاعدة البيانات التي تستخدمها، عادة لا توجد مشكلة في قواعد البيانات المعروفة.


فكرة تجزئة البيانات بعدة جداول - CMT-10 - 09-04-2012

السلام عليكم


قاعدة البيانات المستخدمة ( انا ابتديت اشعر بالخجل من قاعدة البيانات هذه )

أنها أكسس بالطبع

وبصراحة كنت اعتقد انها تفي بالغرض حتى وجدت مقارنة بين قواعد البيانات هذه صورة عنها

http://www.delphi4arab.net/forum/attachment.php?attachmentid=3417&stc=1&d=1333995993


بداية لا اعرف كيف اجريتم العملية ولكن تصورو لو ان هناك جدولين وبهما حقلين احدهما به سعر بضاعة والثاني به المجموع وعدد السجلات 100000 سجل اي ما يعادل 10 الالاف فاتورة تقريبا

وتريد ان تظرب السعر في الكمية بكلتا الجدولين وتعود بالناتج

هل كانت هذه العملية عندكم اقل من عشرون ثانية ....؟

اذا ممكن احد تجربة سريعة اكون له من الشاكرين

وانا الان انتقلت الى SQLLite واجري عليها التجارب الان فيبدوا انها ممتازة للتطبيقات الصغيرة والمتوسطة

وسأرى النتيجة


فكرة تجزئة البيانات بعدة جداول - CMT-10 - 09-04-2012

السلام عليكم


بصراحة جربت Sqllite ووجدت انه رائع فعلا فيما يخص قراءة البيانات بواسطة الدالة Sum
لان القراءة كانت باجزاء من الثانية بينما في الاكسس اخدت مني 15 ثانية

اما فيما يخص اضافة البيانات فقد حاولت اضافة 100000 مئة الف سجل بواسطة تكرار استخدمت فيه الامر For

ولكن تبقى يعمل البرنامج لدقائق حتى اوقفته فوجدت 17000 سجل سبعة عشر الف سجل

والاضافة بهذا الشكل غير مهمة ولكن من ناحية قراءة البيانات واجراء الحسابات هو المهم لان من الضروري اجراء هذه الحسابات

ولا اعتقد ان هناك من يريد اضافة 100000 مئة الف فاتورة بوقت واحد

ولكن الذي يزعجني هو لماذا يقولون هذا الكلام وعندما نجرب نحن نجد ان النتيجة مختلفة تماماً 180 درجة


فكرة تجزئة البيانات بعدة جداول - shagrouni - 09-04-2012

السلام عليكم

أنا استخدم اكسيس أيضا، و بسبب ارتياحي معها تكاسلت عن التغيير لقاعدة بيانات أخرى.

شخصيا لا أرى مشكلة في اكسيس من حيث السرعة، تأكد من أن خاصية CursorLocation = clUseServer
أيضا تأكد من ضبط بعض الخصائص الأخرى لضمان سرعة أعلى.

تجزئة الجدول إلى 12 لا تبدو فكرة جيدة، وستخلق لك مشاكل أكبر في نواح أخرى.


فكرة تجزئة البيانات بعدة جداول - CMT-10 - 10-04-2012

السلام عليكم الله وبركاته

حسنا وحتى اكون منصفا للاكسس فان جملة الاستعلام لها كانت اكثر تعقيدا لانها تتداخل مع جداول اخرى مترابطة

بينما مع SQLLite كانت بشكل عادي مثل

Select Sum(Price * Total) as Finish from Body

واعدت التجربة على قاعدة بيانات اكسس ومع 130000 مئة وثلاثون الف سجل وكانت النتيجة مقبولة

المشكلة التي تواجهني هي عند محاولة العميل اضافة فاتورة مبيعات فكل عملية اضافة لبضاعة يجب التحقق من الكمية هل هي موجودة بالمخزن ام لا وهذا يعني المرور على كل السجلات والقيام بعملية حسابية

والمشكلة ليست بجدول واحد بل يجب حساب البظاعة بجدول المشريات والمبيعات وطرحها من بعضها واظهار النتيجة

او يجب ان اقوم بحدث تحميل النموذج من اجراء هذه العملية لكافة الاصناف بالفواتير المشتريات والمبيعات وخلق مصفوفة منها لاستخدامها في عملية البيع وهذا ايضا سيأخد وقتا .

وبصراحة حنى الان لم اجد حل لهذه المشكلة

وهي مشكلتي الوحيدة مع نظام الفواتير

وهناك حل بديل وهو تخزين كمية كل صنف مع كل عملية بيع وشراء ولكن قال الاخ كاش ون ان هذا مخالف لقواعد انشاء البيانات او قاعدة انشاء البيانات والتي تقول

لا تخزن ما يمكن حسابه


فكرة تجزئة البيانات بعدة جداول - shagrouni - 10-04-2012

السلام عليكم

لم افهم لما الاختلاف في صيغة استعلان sql بين اكسيس وغيرها، ما دام تصميم الجداول هو نفسه.

كنمط معتاد :
يجب أن يكون لدينا جدولا بكميات الأصناف بالمخزن حسب آخر جرد سنوي ،
أي عند اقفال السنة السابقة وفتح سنة جديد.
هذا الجدول لا يتم تغيير الكميات فيه طول السنة و يبقى مرجعا ونسميه رصيد أو السنة.

المشتريات و المبيعات -أو الصادر و الوارد- يكونات في جدول واحد جدول الحركة، و خاص بالسنة الحالية فقط. كميات الصادر/مبيعات تكون في خانة الصادر ، وكميات الوارد/المشتريات/الاستلام تكون في خانة الوارد.

عند انتهاء السنة و بدء سنة جديدة، يتم حساب الفارق بين الصادر و الوارد خلال السنة لكل صنف في جدول الحركة ويضاف لرصيد السنة السايقة في جدول الأصناف. (قبل اجراء هذه العملية تؤخذ نسخة من سجلات جدول الأصناق وتلحق بجدول الأصناف التاريخي الذي فيه خانة اضافية للسنة)

يتم أيضا نسخ جميع التسجيلات في جدول الحركة وإلحاقها في جدول الحركة التاريخي.

يتم تفريغ جدول الحركة،استعدادا لاستقبال حركات السنة الجديدة.

حساب الرصيد لصنف يكون بحساب الفرق بين الصادر والوارد في جدول الحركة + الرصيد في جدول الأصناق.