آه! فهمتك! أي أفكار حول كيف يمكن أن يبدو هذا؟ نحن نبحث دائمًا عن طرق لتسهيل الأمور هنا 
إعجابَين (2)
بالتأكيد! شيء مثل نموذج بيانات Northwind (الشهرة في MS Access!) سيكون رائعًا. قد تكون هناك حتى أداة ستنشئ واحدة من خلال التحقيق في مخطط Postgres.
إعجابَين (2)
هل يمكنك مشاركة ذلك كما لو كنت تتحدث إلى مبتدئ؟ مثل:
- ما الذي سيساعد إضافته في حله؟
- كيف تتوقع رؤية هذا إذا تمت إضافته؟ كيف سيبدو؟
أنا في الأساس آخذ اقتراحك وأطلب المزيد من التفاصيل (قدر ما تستطيع 
) حتى نتمكن من تحسين التجربة لمهندس البيانات التالي الذي سيأتي. ليس لدي أي خلفية في البيانات، لذا سيكون اقتراحك المفصل مفيدًا
إعجابَين (2)
هاها أوسيوكي،
صيحة عادلة جدًا! كلامك صحيح…
لذا يجد معظم الأشخاص الذين يتعاملون مع قواعد البيانات (ليس فقط معماريي البيانات! المطورون أيضًا!) أنه من المفيد جدًا الحصول على نوع من نموذج البيانات الذي يوضح لهم كيفية ربط الجداول المختلفة ببعضها البعض.
على سبيل المثال، دعنا نأخذ استعلامي ؛)، كنت بحاجة إلى عدة قطع من المعلومات حول مستخدم - كنت بحاجة إلى معلومات حول مستخدم:
- كان في (أو لم يكن في) مجموعة معينة
- حل موضوعًا
- ضمن نطاق تاريخي معين
للإجابة على ما سبق، أحتاج إلى جدول المستخدمين، وجدول إجراءات المستخدم، وجدول المجموعات. سيُظهر لي نموذج البيانات أنه يمكنني ربط مستخدم بإجراء مستخدم عبر id/user_id، وربط مستخدم بمجموعة عبر primary_group_id/id الخاص به بصريًا.
يساعد في تصور ليس فقط البيانات المتاحة، ولكن كيفية ربطها، خاصة إذا كانت هناك بعض الاستعلامات الطويلة قيد التشغيل.
نعم، يمكنك النقر فوق كل جدول في مستكشف البيانات لمعرفة الحقول المتاحة وكتابتها حتى لا تنساها، ولكن وجود نموذج بيانات قد يكون أكثر إنسانية بالنسبة للبعض منا
5 إعجابات
آه! لقد فهمتك مرة أخرى! 
أنا لست تقنيًا، لذلك لم يكن هذا واضحًا بالنسبة لي. أنا أرى الحاجة، لذا نعم. نموذج البيانات هو شيء سيكون مفيدًا. دعني أرى ما يمكنني فعله.
في هذه الأثناء، قمت بنقل هذه المحادثة إلى موضوع جديد في فئة Site feedback لدينا حتى نحافظ على نظافة المناقشة الأخرى.
إعجابَين (2)
سيكون ذلك مذهلاً، شكراً لك!
إعجاب واحد (1)
إذًا، أنا أتحدث مع الفريق وهذا ليس شيئًا سيكون مباشرًا لأسباب عديدة. لقد نقلناه أيضًا إلى 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.