آه! فهمتك! أي أفكار حول كيف يمكن أن يبدو هذا؟ نحن نبحث دائمًا عن طرق لتسهيل الأمور هنا 
إعجابَين (2)
بالتأكيد! شيء مثل نموذج بيانات Northwind (الشهرة في MS Access!) سيكون رائعًا. قد تكون هناك حتى أداة ستنشئ واحدة من خلال التحقيق في مخطط Postgres.
إعجابَين (2)
هل يمكنك مشاركة ذلك كما لو كنت تتحدث إلى مبتدئ؟ مثل:
- ما الذي سيساعد إضافته في حله؟
- كيف تتوقع رؤية هذا إذا تمت إضافته؟ كيف سيبدو؟
أنا في الأساس آخذ اقتراحك وأطلب المزيد من التفاصيل (قدر ما تستطيع 
) حتى نتمكن من تحسين التجربة لمهندس البيانات التالي الذي سيأتي. ليس لدي أي خلفية في البيانات، لذا سيكون اقتراحك المفصل مفيدًا
إعجابَين (2)
هاها أوسيوكي،
صيحة عادلة جدًا! كلامك صحيح…
لذا يجد معظم الأشخاص الذين يتعاملون مع قواعد البيانات (ليس فقط معماريي البيانات! المطورون أيضًا!) أنه من المفيد جدًا الحصول على نوع من نموذج البيانات الذي يوضح لهم كيفية ربط الجداول المختلفة ببعضها البعض.
على سبيل المثال، دعنا نأخذ استعلامي ؛)، كنت بحاجة إلى عدة قطع من المعلومات حول مستخدم - كنت بحاجة إلى معلومات حول مستخدم:
- كان في (أو لم يكن في) مجموعة معينة
- حل موضوعًا
- ضمن نطاق تاريخي معين
للإجابة على ما سبق، أحتاج إلى جدول المستخدمين، وجدول إجراءات المستخدم، وجدول المجموعات. سيُظهر لي نموذج البيانات أنه يمكنني ربط مستخدم بإجراء مستخدم عبر id/user_id، وربط مستخدم بمجموعة عبر primary_group_id/id الخاص به بصريًا.
يساعد في تصور ليس فقط البيانات المتاحة، ولكن كيفية ربطها، خاصة إذا كانت هناك بعض الاستعلامات الطويلة قيد التشغيل.
نعم، يمكنك النقر فوق كل جدول في مستكشف البيانات لمعرفة الحقول المتاحة وكتابتها حتى لا تنساها، ولكن وجود نموذج بيانات قد يكون أكثر إنسانية بالنسبة للبعض منا
5 إعجابات
آه! فهمتك مرة أخرى! 
لستُ شخصاً تقنياً، لذا لم يكن الأمر واضحاً بالنسبة لي. لكنني أدرك الحاجة إليه، لذا نعم. نموذج البيانات شيء سيكون مفيداً. دعني أرى ما يمكنني فعله.
في هذه الأثناء، نقلت هذه المحادثة إلى موضوع جديد في فئة Contribute > Site feedback لدينا حتى نحافظ على نقاشات أخرى نظيفة.
إعجابَين (2)
سيكون ذلك مذهلاً، شكراً لك!
إعجاب واحد (1)
لذا أنا أتحدث مع الفريق، وهذا ليس أمرًا مباشرًا لعدة أسباب. قمنا أيضًا بنقله إلى Contribute > Feature لأن ذلك يوضح بشكل أفضل ما سيكون عليه الأمر.
في الوقت الحالي، نحن الذين نعمل مع البيانات داخليًا نستخدم بشكل أساسي النماذج المتاحة في شفرة المصدر:
لقد قمت أيضًا بإلقاء نظرة على نموذج بيانات Northwind:
هذا بالتأكيد سهل الفهم ويتسع للورقة أو شاشة واحدة. 13 جدولًا في المجموع.
مقارنةً بذلك مع Discourse، لدينا عدد أكبر بكثير من الجداول، أكثر من 180 أو أكثر، وتصور هذا سيكون … رحلة شاقة. خاصة لأن هناك أيضًا جداول من الإضافات (وهذه تتغير من تثبيت لآخر) وبيانات في جداول *_custom_fields والتي يجب تضمينها أيضًا إذا أردت حقًا الحصول على صورة كاملة.
أيضًا بسبب كيفية تصميم قاعدة البيانات لدينا، لا يمكننا استخدام معظم أدوات نمذجة البيانات، سنحتاج إلى العثور على واحدة تعمل مع نماذج ActiveRecord. وأعتقد أن هذا يجعل الأمر محيرًا أيضًا، كل هذه المناقشات المتعلقة بالبيانات فوق مستوى فهمي.
ولكن هذا لا يعني أننا لا نريد القيام بذلك، هذا مجرد تعليق. أود أن أسمع اقتراحات منكم أو من أي شخص آخر حول الطرق التي يمكننا من خلالها تحسين هذا الأمر.
6 إعجابات
ليس مفيدًا حقًا ، نظرًا لحجمه الهائل ، ونقص المفاتيح الخارجية ، وعدم تركنا سوى القليل من المنطق لنظام إدارة قواعد البيانات العلائقية ، مما يجعل من الصعب فهم قاعدة بيانات Discourse دون قراءة مصدر Discourse.
ولكن إذا كنت بحاجة إليه حقًا ، فيمكن لـ RubyMine إنشاؤه لك.
14 إعجابًا
يمكنك إنشاء واحد بعلاقات مع rails-erd: GitHub - voormedia/rails-erd: Generate Entity-Relationship Diagrams for Rails applications
لست متأكدًا من مدى فائدة هذا على الرغم من ذلك
10 إعجابات
@lju آمل أن تساعد كل شروحاتنا هنا، خاصة مع السياق المضاف. سأقوم بإغلاق هذا في غضون يوم أو يومين. إذا كنت لا تزال تشعر أنك بحاجة إلى بعض التفاصيل الإضافية، فلا تتردد في السؤال.
3 إعجابات
مرحباً @osioke،
آسف للتأخير في الرد، لقد كنت مشغولاً للغاية.
لدي بعض الأفكار حول ما سيكون مفيدًا - إذا كان بإمكانك منحي بضعة أيام، فسأقوم بكتابة شيء ما.
تحياتي،
Lju
إعجاب واحد (1)
رائع! لديك بضعة أيام الآن شكراً لاهتمامك بهذا الأمر.
مرحباً بالجميع،
لذا، ستكون حجتي هي أن نموذج البيانات سيكون مفيدًا، ولكن لا نحتاج بالضرورة إلى تضمين جميع الجداول. أشك في أنه ربما تكون هناك الجداول “الأساسية” البالغ عددها 15-25 جدولًا تقريبًا والتي تستخدمها 90٪ من جميع الاستعلامات/ما يبحث عنه الأشخاص. في الواقع، بالنظر إلى الجداول المختلفة المتاحة - هناك ربما سلسلة من نماذج البيانات التي يمكن إنشاؤها، بناءً على أنواع الاستعلامات/البيانات التي تتطلع إلى استكشافها.
يمكنني أن أحاول خلال الأيام القليلة القادمة تجميع ما أعتقد أنه سيكون الجداول الأكثر استعلامًا - لن يكون هذا بحثًا شاملاً، مجرد تخمين. أنا متأكد من أن الأسئلة المختلفة المطروحة في فئة مستكشف البيانات ستسلط الضوء أيضًا على الجداول الشائعة.
يمكن أيضًا أن يكون هناك رسم تخطيطي آخر لتمثيل “مناطق” الاهتمام لتسهيل التنقل في أجزاء مختلفة من البيانات المتاحة.
هل هذا منطقي؟
تحياتي،
Lju
6 إعجابات
يُدرج مستكشف البيانات بالفعل أهم 9 جداول أولاً في لوحة واجهة مستخدم تحرير الاستعلام، ويمكنك رؤية بنية الأعمدة وأنواعها لجميع الجداول بنقرة واحدة:
3 إعجابات
إذًا، يمكننا أخذ تلك الجداول التسعة وتحويلها إلى نموذج بيانات مبسط؟ 
5 إعجابات
بالتأكيد، تفضل بمشاركة النتائج!
4 إعجابات
هذا ضخم جداً؛ أحد أكبر مخططات قواعد البيانات التي رأيتها على الإنترنت
هل تم إنشاؤه باستخدام https://dbdiagram.io؟ هل يمكنك مشاركة الرابط العام للمخطط؟
أنا مهتم أكثر بالعلاقات والروابط بين هذه الجداول
users،
user_options،
api_keys،
user_api_keys،
user_auth_tokens،
user_auth_token_logs،
notifications
شكراً
مفيد جدًا ولكن سيكون رائعًا الحصول على عنوان URL قابل للمشاركة حتى نتمكن من رؤية علاقات الجداول والمفاتيح الأساسية/الخارجية في الجداول
هل هناك أي علاقات 1 إلى 1 في المخطط؟ سأحب أن أعرف خاصة بين جدولي users و user_options
هل هناك أي شخص مستعد للمساعدة في العلاقات بين هذه الجداول؟ من مخطط المخطط
users,
user_options,
api_keys,
user_api_keys,
user_auth_tokens,
user_auth_token_logs,
notifications
مهتم بمعرفة ما إذا كانت هناك علاقات واحد لواحد
سأكون ممتنًا.. شكرًا
م.م. @Falco @sam
إنها في الغالب 1-N، حيث يمتلك المستخدمون إشعارات متعددة، ورموز مصادقة، وما إلى ذلك.
user_options هي 1-1.