السلام عليكم ورحمة الله

انا عندى فكرة في مشروعى في الديزاين _ انى عايز أقسم جدول ل entity
الى جدولين

وليكن مثال على الموظفين _
لو عندى جدول موظفين وعايز أشوف الموظفين اللى طلعوا ع المعاش _
وكانت كل خواص الموظفين بياناتهم وأجورهم ومراكزهم موجودة في جدول الموظفين

فلما موظف يطلع ع المعاش _ انا عندى لها حلين _
1) انى اعمل عمود في جدول الموظفين True/False ولو كان ب true يبقى الموظف دة فعلاً طلع ع المعاش
بس في الحالة دى لازم ازود اعمدة في جدول الموظفين عشان أعرف هو امتى طلع ع المعاش _ ومثلاً المعاش بتاعه كام _ ويبقى كدة
انا محتفظ بكل بياناته اللى انا محتاجها _ وكمان عرفت انه طلع ع المعاش _ وأقدر بعد كدة اتعامل معاه بالبرنامج بالكوود _ عشان اتصرف معاه
بس دة أولاً له مشاكل :- انه حيصعب الكود وحيطوول البحث لو انا عايز أدور على الموظفين اللى عندى _ لازم أستبعد اللى العمود بتاع المعاشات ب true
وكمان حيخلى الجدول كبييير وفيه أجزاء كبيرة مالهاش لازمة اللى هى حتكون اعمدة تاريخ خروجه ع المعاش والمعاش بتاعه كام بالنسبة للى لسة متوظفين .

2) انى أعمل جدول جديد للمعاشات واخد منه كل الموظفين اللى طالعين دلوقتى ع المعاش _ واخد بياناتهم تقريباً نص البيانات اللى محتاجها من جدول الموظفين
وامسح بياناتهم اللى في جدول الموظفين ماخليش منها أى حاجة تخص الموظف
ويبقى كل البيانات السابقة له اللى انا محتاجها والبيانات الجديدة اللى تخص المعاشات انا احظها في جدول المعاشات
فدة حيسهل لى في الكود _ وخيخلينى عارف ادور ع الموظفين فين ؟ والمعاشات فين _

بس مشكلته ان نفس اعمدة البيانات اللى هنا هى نفسها حلاقيها هنا وان فيه كدة أعمدة تتكرر ما بين الجدولين !!!!
فانا محتار في الموضوع دةةة _


على فكرة انا ضارب مثال الموظفين _ مع ان مشروعى مش شئون عاملين ولا حااجة _ انا بس مش عايز اخخد مساعدة مباشرة في مشروعى
وانا بفكر في فكرة الجدولين __ من منظلق انى بعمد داتا بيز لشئون طلبة _ وعايز اقسم جدول الطلبة لجدول خريجين كمان _
بدل ما أعمل خانة لجريج true/false يعنى نفس النظام اللى في جدول الموظفين والمعاشات _
وكمان برده في قاعدة بيانات مكتبة _ عايز أعمل جدول صغير للكتب المفقودة عن الكتب الأساسية _ لان فيه بيانات زيادة
حتكون مين المسئول عن ضياع الكتاب _ وامتى الكتاب ضاع وكدةة _ وكمان لما أعمل جدول جديد واشيل الكتب المفقودة من الجدول الأساسى للكتب _
حيسهل لى عمل استعارة سهل في الكود وحيخلينى اشوف كل شروط الإستعارة من غير ما أشوف ان الكتاب دة مفقود ولا لأا علماً بان الإستعارة
شروطها كتيييييييير جداً ولازم أشوف كام نسخة من الكتاب موجودة _ وماينفعش الإستعارة لاى كتاب الا لو كان فيه نسخة واحدة ع الأقل موجودة في المكتبة

فياريتكم تفيدونى في النظرية دىى _ وياترى هى فيها مشاكل من ناحية ال normalization ولا حااجة _ ولا عادى انى أعمل جدولين
والأغمدة معظمها متشابة _ وخلوا ردكم على مثال الموظفين والمعاشات



ومنتظر أرائكم سريعاااا من فضلكم _ لان معاد مناقشة المشروووع قررب _ وانا عايز أدخل في الفورمز بأسرع وقت

أخي الحبيب حلك الاول هو الافضل بإذن الله
وهو الادق

شكراً لردك أخى مصطفى _

بعنى مفيش مشاكل انى أضع أعمدة زيادة تكون معظمها ب null في الجدول ؟
__ وبرده السيرش مش حبقى فيه مشكلة في التعقيد بتاعه ؟

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

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

الطريقة الأولي صحيحة ، أما الثانية صح الصح !!!!

بص يا أخي ، هناك 3 أخطاء دائماً المبرمجين بيقعو فيها وهي كالتالي :

1- وجود جدول يحتوي علي حقول ليس له علاقة بالجدول الحالي ، علي سبيل المثال "جدول الموظف" يتضمن بيانات الفصل أو المعاشات أو ترك العمل .
2- وجود حقول متروكة عمداً في كثير من السجلات Null لأنها لا تتطابق معها ، وغالباً يكون هذه الحقول تخص جداول أخري ، يعني مثلاً حقول الـ FK .
3- قد يكون هناك عدداً كبيراً من الجداول التي تحتوي علي نفس الحقول ، يعني مثلاً جدول للموظفين وجدول للمشرفين .. أو مثلاً إسم الموظف مدرج في أكثر من جدول ، مثلاً في جدول الموظف وجدول الإدارة "مدير القسم".

لكل هذه الأسباب يا ريت تنظر الي الطريقة الثانية هيكون أفضل بكثر

بالإضافة الي المرونة التي من خلالها تتمكن من التطويل المستقبلي



بالتوفيق

Tables.bmp

أشكر ردك أخى MMA

بس حضرتك كدة حتحل المشكلة جزئياً _
انا كنت أقصد بالطريقة الثانية
انى احذف بيانات الموظفين بالكامل من جدول الموظفين
واضعها في جدول المعاشات _ يعنى بكدة مش حيبقى فيه ربط ما بين جدول الموظفين والمعاشات

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

بس أى كاان _ سيبك من موضوع الكوود : حتتحل ان شاء الله في كل الطرق _
الكود مش مشكلة __

يعنى رأيك حضرتك انى أترك بيانات الموظفين كلهم زى ما هى _ ولو حد طلع ع المعاش أعمل له فورين كيي في جدول المعاشات
واحط البيانات الإضافية له في المعاشات ؟؟ وفي الحالة دى طبعاً حيبقى الربط one -to -one

ولا انى أشيل بيانات الموظفين خالص من جدول الموظفين وأعملهم Move في جدول المعاشات
واحط بياناتهم الأساسية والزيادة في جدول المعاشات _ ودى طريقتى التانية اللى وضحتها فووق ؟؟

ومتظر ردك واشكرك

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

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

وعايز أعرف اعمل ايه عشان أوصل للموظفين اللى طلعوا ع المعاش

فالحل الاول :-

انى ازود حقول مع جدول الموظفين ( على المعاش T/F - تاريخ المعاش - مرتب المعاش )

الحل التانى :-

انى اعمل جدول خاص بالمعاشات وأى موظف يطلع ع المعاش
أعمل له Move من جدول الموظفين الى جدول المعاشات
وبالتالى حيكون لجدول المعاشات الحقول ( اسم - عنوان-هاتف- اخر مرتب-اخر وظيفة - تاريخ المعاش - مرتب المعاش )

الحل الثالث :
اللى قاله الأخ MMA
أنى اترك بيان الموظف زى ما هو في جدول الموظفين _ واعمل جدول جديد للمعاشات فيه الحقول ( تاريخ المعاش - مرتب المعاش - رقم الموظف )
وأربط رقم الموظف في جدول المعاشات برقم الموظف في جدول الموظفين بعلاقة تبين لى ان الموظف دة طلع ع المعاش
وبالتالى في جدول الموظفين حعرف ازااى ان الموظف طلع ع المعاش ولا لأا ؟ عن طريق انى اقارن الأرقام المتشابهة في جدول الموظفين والمعاشات
ولو الأرقام متشابهة يبقى الموظف فعلاً طلع ع المعاش _ انما لو رقم موظف موجود في جدول الموظفين ومش وموجود في جدول المعاشات
يبقى الموظف لسة ماطلعش ع المعاش

ومنتظر ردك ان شاء الله

السلام عليكم ورحمة الله وبركاته
أعتقد الاختيار هيكون من بين الحل الاول والثالث
بمعنى عملية نقل البيانات دي غير عملية
الطريقة الاولى من وجهة نظري لــــ
وإذن يتم الاحتفاظ بكل الموظفين في نفس الجدول وطالما ان التحديث سيكون في اعمدة يعني علاقة ONE TO ONE أقصد ان المعاش مرحلة تحدث مرة واحدة فقط إذن لامانع يتم وضع هذه الاعمدة في نفس الجدول وبعد مرحلة معينة يتم تحديث البيانات
فلذا ارشح لك الطريقة الاولى حيث يتم التعرف على الموظف انه في حالة المعاش من خلال عمود حالة الموظف إما معاش أو لسه
وهي هتسهل كتير عليك
لكن عمل جدول اخر أعتقد أنها ملهاش ضرورة وخصوصا ان الموظف بيطلع معاش مرة واحدة يعني مش بيحدث تغيرات له يعني مش هيكون ديتيل في جدول المعاشات
مع كامل احترامي لدرش MMA
وشكرا للجميع

شكراً ليك _ وجهة نظر أحترمها
ومنتظر بقية الاراء

السلام عليكم
كل الاحترام لوجهات النظر ولكن من وجهة نظري أفضل تقسيم الجداول حيث أن جدول الموظفين لا يقتصر فقط على المعاشات وانما ايضا على الاجازات السنوية والمرضية بالاضافة الى السلف واوقات المغادرة....
فالأفضل تقسيم جدول الموظفين....وعمل RELATIONS
بالتوفيق

تم تعديل 21 مايو 200916 سنة بواسطة PALI.ORACLE

السلام عليكم
كل الاحترام لوجهات النظر ولكن من وجهة نظري أفضل تقسيم الجداول حيث أن جدول الموظفين لا يقتصر فقط على المعاشات وانما ايضا على الاجازات السنوية والمرضية بالاضافة الى السلف واوقات المغادرة....
فالأفضل تقسيم جدول الموظفين....وعمل RELATIONS
بالتوفيق

هو دة الكلام المظبوط ، المفروض أن فية أجازات وعلاوات وخلافة غير المعاشات ، هل معني كدة أني هعمل نسخ لبيانات المستخدم ؟؟؟

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

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

بالعكس عملية النسخ في حد ذاتها بتكون أبطأ ، وبعدين يا أخي ما المانع في جلب بيانات محددة وصناعة ما نشاء !!!

إذا كان من الممكن يمكنك إرتجاع كافة سجلات الموظفين المحالين للمعاش ، فمن الممكن أيضاً إرتجاع كافة سجلات الموظفين الغير محالين للمعاش وعمل عمليات عليها بكل سهولة وبدون أي إشكاليات !!!

علشان نسهل الأمور هعرض عليك مثال عملي :

لدينا جدولين ، الأول جدول الموظف والثاني جدول الموظفين المحالين علي المعاش كما يلي :

CREATE TABLE EMP
(
 EMP_ID  NUMBER(10) PRIMARY KEY,
 EMP_NAME VARCHAR2(50) UNIQUE NOT NULL
)
/
CREATE TABLE STIPEND
(
 STIPEND_ID  NUMBER(10) PRIMARY KEY,
 STIPEND_EMPID  NUMBER(10) REFERENCES EMP(EMP_ID),
 STIPEND_DATE   DATE NOT NULL,
 STIPEND_SALARY NUMBER(20,3) NOT NULL,
 STIPEND_FOR	VARCHAR2(255)
)
/
INSERT INTO EMP VALUES(1,'Ahmed');
INSERT INTO EMP VALUES(2,'Dina');
INSERT INTO EMP VALUES(3,'Mostapha');
INSERT INTO EMP VALUES(4,'Mahmod');
INSERT INTO EMP VALUES(5,'Mohammed');
COMMIT;
INSERT INTO STIPEND VALUES(1,2,SYSDATE,1500,'معاش مبكر بسبب حالتة المرضية');
INSERT INTO STIPEND VALUES(2,4,SYSDATE,1350,'معاش كامل');
COMMIT;

الطبيعي أنني في حالة الإحتياج الي كافة معلومات الموظفين المحالين للمعاش يجب عمل علاقة Inner Join بين الجدولين لتصبح كما يلي :

SELECT EMP_ID, EMP_NAME
FROM EMP INNER JOIN STIPEND ON EMP.EMP_ID = STIPEND.STIPEND_EMPID;

ولكن كيف يمكنني أن أصنع إستعلام بسيط يجلب ليا كافة الموظفين الذين لم يتم إحالتهم علي المعاش ؟؟؟؟

انظر الفكرة :

SELECT EMP_ID,EMP_NAME
FROM EMP
WHERE (SELECT COUNT(0) FROM STIPEND WHERE STIPEND_EMPID = EMP.EMP_ID) = 0;

وبهذه الفكرة تكون حليت كل مشاكلك ، وقسمت الجداول بالمنطق ، وصممت بنية قوية قابلة للتطوير المستقبلي

أما بخصوص السرعة فالموضوع مش هيكون بطيء ، بالعكس كلما تم تقسيم الجداول الي أسلوب علمي صحيح وإستخدمنا جمل الـ SQL بصفة دورية هتكون العملية سريعة وليس هناك أي إشكاليات




سؤال آخر بعيد عن الموضوع ، هو لية الشعب العربي بيحب يدور علي أسهل الطرق وبعدين يعتمدها ؟؟؟ ولية هذا الموضوع هو أللي ماشي في السوق ؟؟؟

مع العلم أن أسهل الطرق دائماً تجعلني غير متخذ للقرارات الكبري في التصاميم المعقدة علمياً ، لكن أصعب الطرق وأنجحها تجعلني ملم باللغة التي أتقنها ؟؟؟

دة انا عنيت من المشكلة دي كثير جداً ، ومش لاقي لها حل علي الإطلاق




بالتوفيق الدائم للجميع

السلام عليكم
كل الاحترام لوجهات النظر ولكن من وجهة نظري أفضل تقسيم الجداول حيث أن جدول الموظفين لا يقتصر فقط على المعاشات وانما ايضا على الاجازات السنوية والمرضية بالاضافة الى السلف واوقات المغادرة....
فالأفضل تقسيم جدول الموظفين....وعمل RELATIONS
بالتوفيق

هو دة الكلام المظبوط ، المفروض أن فية أجازات وعلاوات وخلافة غير المعاشات ، هل معني كدة أني هعمل نسخ لبيانات المستخدم ؟؟؟

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

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

بالعكس عملية النسخ في حد ذاتها بتكون أبطأ ، وبعدين يا أخي ما المانع في جلب بيانات محددة وصناعة ما نشاء !!!

إذا كان من الممكن يمكنك إرتجاع كافة سجلات الموظفين المحالين للمعاش ، فمن الممكن أيضاً إرتجاع كافة سجلات الموظفين الغير محالين للمعاش وعمل عمليات عليها بكل سهولة وبدون أي إشكاليات !!!

علشان نسهل الأمور هعرض عليك مثال عملي :

لدينا جدولين ، الأول جدول الموظف والثاني جدول الموظفين المحالين علي المعاش كما يلي :

CREATE TABLE EMP
(
 EMP_ID  NUMBER(10) PRIMARY KEY,
 EMP_NAME VARCHAR2(50) UNIQUE NOT NULL
)
/
CREATE TABLE STIPEND
(
 STIPEND_ID  NUMBER(10) PRIMARY KEY,
 STIPEND_EMPID  NUMBER(10) REFERENCES EMP(EMP_ID),
 STIPEND_DATE   DATE NOT NULL,
 STIPEND_SALARY NUMBER(20,3) NOT NULL,
 STIPEND_FOR	VARCHAR2(255)
)
/
INSERT INTO EMP VALUES(1,'Ahmed');
INSERT INTO EMP VALUES(2,'Dina');
INSERT INTO EMP VALUES(3,'Mostapha');
INSERT INTO EMP VALUES(4,'Mahmod');
INSERT INTO EMP VALUES(5,'Mohammed');
COMMIT;
INSERT INTO STIPEND VALUES(1,2,SYSDATE,1500,'معاش مبكر بسبب حالتة المرضية');
INSERT INTO STIPEND VALUES(2,4,SYSDATE,1350,'معاش كامل');
COMMIT;

الطبيعي أنني في حالة الإحتياج الي كافة معلومات الموظفين المحالين للمعاش يجب عمل علاقة Inner Join بين الجدولين لتصبح كما يلي :

SELECT EMP_ID, EMP_NAME
FROM EMP INNER JOIN STIPEND ON EMP.EMP_ID = STIPEND.STIPEND_EMPID;

ولكن كيف يمكنني أن أصنع إستعلام بسيط يجلب ليا كافة الموظفين الذين لم يتم إحالتهم علي المعاش ؟؟؟؟

انظر الفكرة :

SELECT EMP_ID,EMP_NAME
FROM EMP
WHERE (SELECT COUNT(0) FROM STIPEND WHERE STIPEND_EMPID = EMP.EMP_ID) = 0;

وبهذه الفكرة تكون حليت كل مشاكلك ، وقسمت الجداول بالمنطق ، وصممت بنية قوية قابلة للتطوير المستقبلي

أما بخصوص السرعة فالموضوع مش هيكون بطيء ، بالعكس كلما تم تقسيم الجداول الي أسلوب علمي صحيح وإستخدمنا جمل الـ SQL بصفة دورية هتكون العملية سريعة وليس هناك أي إشكاليات




سؤال آخر بعيد عن الموضوع ، هو لية الشعب العربي بيحب يدور علي أسهل الطرق وبعدين يعتمدها ؟؟؟ ولية هذا الموضوع هو أللي ماشي في السوق ؟؟؟

مع العلم أن أسهل الطرق دائماً تجعلني غير متخذ للقرارات الكبري في التصاميم المعقدة علمياً ، لكن أصعب الطرق وأنجحها تجعلني ملم باللغة التي أتقنها ؟؟؟

دة انا عنيت من المشكلة دي كثير جداً ، ومش لاقي لها حل علي الإطلاق




بالتوفيق الدائم للجميع

شكراااااً جدا جدا جدااا _ أن أؤيد الطريقة دى أيضاً _
ولقد أبدعت صراحة في الرد على مشكلتى أخى MMA
وبالكود أيضاً _ جزاك الله كل خيير _

وصراحة أنا ماكنتش بدوور على أسهل الطرق _ لا والله اكيد طبعاً أصعب الطرق بتؤدى الى الأفضل ولكن مش في كل الأحيان _
ولكن كنت اود اصل الى الأفضل نظرياً وعلمياً _

وسأقوم باتخاذ الطريقة في كل من جدول الخريجين والكتب المفقودة في المكتبة _
تسلموااا جميعاً
والف شكر

تمام اخي MMA هذا ما قصدته بالزبط
الله يعطيك العافيه

هو الموضوع لو 3 أعمدة ليه يتم عمل عمل جدول تاني
لكن التقسيم لابد منه لو هيحصل تكرار زي الاجازات والرواتب
وكده

شكراااااً جدا جدا جدااا _ أن أؤيد الطريقة دى أيضاً _
ولقد أبدعت صراحة في الرد على مشكلتى أخى MMA
وبالكود أيضاً _ جزاك الله كل خيير _

وصراحة أنا ماكنتش بدوور على أسهل الطرق _ لا والله اكيد طبعاً أصعب الطرق بتؤدى الى الأفضل ولكن مش في كل الأحيان _
ولكن كنت اود اصل الى الأفضل نظرياً وعلمياً _

وسأقوم باتخاذ الطريقة في كل من جدول الخريجين والكتب المفقودة في المكتبة _
تسلموااا جميعاً
والف شكر

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

هل معني ذلك أنني كمبرمج لم أنظر الي أسهل الطرق ... لو قلت هكذا أبقي كذاب !!!

ولكن بغض النظر عن أسهل الطرق ، المنطق كيف يكون ؟؟؟؟

هو الموضوع لو 3 أعمدة ليه يتم عمل عمل جدول تاني
لكن التقسيم لابد منه لو هيحصل تكرار زي الاجازات والرواتب
وكده

بص يا أخي كلامك صحيح ، بس أنا قلت في المشاركة رقم ( 5 ) وهي مشاركتي الأولي

أنا ذكرت أن هناك بعض الأخطاء الشائعة التي يتعرض لها أي مبرمج ، وهي وجود قيمة Null متعمداً في سجلات البيانات ، طيب سؤال الحقول الثلاثة في نفس الجدول هل تضمن أن الموظف يخرج علي المعاش ويكون له معاش ، أم يستقيل ويذهب الي وظيفة أخري ، أم أم أم ؟؟؟؟

وإلي متي ستظل هذه الحقول تحمل قيمة Null ، الي أن يخرج علي المعاش "سن الستين للذكور والـ 55 للإناث" علي ما أعتقد.

وبغض النظر عن كل هذا ، أليس من الممكن أن يستقيل الموظف ومن ثم يرجع مرة أخري الي نفس المكان ونفس الوظيفة من الصفر !!!

لذلك أنا بحب أدرج بيانات أخري زي :
1- جدول لبيان الحكاية أو السيناريو الوظيفية.
2- جدول لترك العمل ( في حالة إستقالتة أو حصولة علي المعاش ).

ففي هذه الحالة سيكون هناك حقول رئيسية مكونة من :
1- تاريخ ترك العمل.
2- سبب ترك العمل(معاش-إستقالة-آخر).
3- راتب المعاش ( وفي حالة إستقالتة يبقي مفيش معاش ، يبقي بردو مينفعش أخليها Null ولكن أدرج لها قيمة صفرية ).


المهم أللي أنا عاوز أوصل إلية أن فية أشكال كثيرة وصحيحة لبناء التصميمات المعمارية "آسف تصميمات قاعدة البيانات" ولكن هناك صح الصح ... ومن وجهة نظر تحليل النظم أن لا يجب أن يتم وضع أي بيانات في جدول ليس له علاقة به ، وعدم وجود قيمة Null علي قدر المستطاع ، وعدم التكرار الدائم

وبغض النظر عن كل هذا ، هل من العقل أن تصنع جدول للموظف يحتوي مثلاً علي 100 حقل ، من ضمنهم حقول كثيرة ستحمل قيمة Null حسب ظروفها الخاصة ؟؟؟

حتي ولو مش هتحمل قيمة Null ، هل يعقل أن تجعل جدول يحتوي علي 100 حقل بدلاً من تقسيم العمل ؟؟؟

بإختصار شديد دع قيمة Null لحقول العلاقات فقط لا غير ، وعلي قدر المستطاع أن حاول تلغي هذه القيمة


هي مش وحشة ، ولكن سبب وجودها عدم إستخدام المنطق الصحيح ، فأي برنامج يتم ربطه مع قاعدة بيانات تحتوي علي الثلاثة مشاكل المذكورة في المشاركة رقم "5" ، يبقي مصمم البرنامج وقع في هذه الأخطاء ، وهذه مشكلة يقع فيها الكثيرون ولم يقم بتحليل النظام بصورة جيدة !!!!







بالتوفيق للجميع

تماااااااام _ اتفق معك أخى MMA

وشكراً على المدونة المتميزة _ جارى تحميل ال report builder

ممكن تنظرو معي علي هذا الرابط

هنا

معلش لو مكنتش مشغول كنت صنعت الشرح بنفسي






بالتوفيق