هل تستخدم أنواع بيانات SQL المعرفة من قبل المستخدم كثيرًا؟ [مغلق

Question

أخبرتني DBA الخاص بي استخدام نوع بيانات SQL المعرفة من قبل المستخدم لتمثيل العناوين ، ثم استخدام عمود واحد من هذا النوع الجديد في جدول المستخدمين لدينا بدلاً من أعمدة العنوان المتعددة. لم أفعل هذا من قبل وأتساءل عما إذا كان هذا نهجًا شائعًا.

أيضًا ، ما هو أفضل مكان للحصول على معلومات حول هذا - هل هو خاص بالمنتج؟

Answer 1

هناك عدد من الأسئلة الأخرى على لذا حول كيفية تمثيل العناوين في قاعدة بيانات. AFAICR ، لا أحد منهم يشير إلى نوع محدد من قبل المستخدم لهذا الغرض. لن أعتبره نهجًا شائعًا ؛ هذا لا يعني أنه ليس مقاربة معقولة. تكمن الصعوبات الرئيسية في تحديد الطرق التي يجب توفيرها لمعالجة بيانات العنوان - تلك المستخدمة لتنسيق البيانات لتظهر على مظروف ، أو في أماكن محددة في نموذج مطبوع ، أو لتحديث الحقول ، والقلق بشأن العديد من تداعيات العناوين الدولية ، وهلم جرا.

تحديد الأنواع المعرفة من قبل المستخدم هو محدد للغاية للمنتج. تختلف الطرق التي تقوم بها في Informix عن الطرق التي يتم بها في DB2 و Oracle ، على سبيل المثال.

Answer 2

بقدر ما أستطيع أن أقول ، على الأقل في عالم SQL Server ، لا تستخدم UDT كثيرًا.

المشكلة مع UDT هي حقيقة أنه لا يمكنك تحديثها بسهولة. بمجرد إنشائها واستخدامها في قواعد البيانات ، فإنها تقريبًا مثل وضع الحجر.

لا يوجد أمر "إنشاء أو تغيير (udt)": --( لذا لتغيير شيء ما ، عليك أن تفعل الكثير من الخلط حولها - ربما يتم نسخ البيانات الموجودة ، ثم إسقاط الكثير من الأعمدة من الجداول الأخرى ، ثم إسقاط UDT ، إعادة ، -إنشاءه بالهيكل الجديد وإعادة تطبيق البيانات وكل شيء.

هذا الكثير من المتاعب - وأنت تعرف: هناك إرادة كن التغيير!

في الوقت الحالي ، في SQL Server Land ، تعتبر UDT مجرد فكرة لطيفة - ولكن تم تنفيذها بشكل سيء حقًا. لا أوصي باستخدامها على نطاق واسع.

مارك

Answer 3

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

بدلاً من ذلك ، إذا كنت تستخدم أي لغة موجهة للكائن ، قم بإنشاء علاقة تكوين لتحديد عناوين الموظف (على سبيل المثال) وتخزين العناوين في جدول منفصل.

على سبيل المثال. جدول الموظفين وجدول الموظف. يمكن للموظف واحد أن يكون له عناوين متعددة.

Answer 4

نوع بيانات SQL المعرفة من قبل المستخدم لتمثيل العناوين

يمكن أن تكون الأنواع المعرفة من قبل المستخدم مفيدة للغاية ، لكن العنوان البريدي لا يقفز كأحد هذه الحالات (بالنسبة لي ، على الأقل). ما هو العنوان البريدي لك؟ هل هو شيء تطبعه على مظروف لإرسال شخص ما؟ إذا كان الأمر كذلك ، فإن النص جيد كما سيحصل عليه. إذا كنت بحاجة إلى معرفة الحالة التي يوجد فيها شخص ما لأسباب قانونية ، فقم بتخزين ذلك بشكل منفصل وليس مشكلة.

انتقدت المشاركات الأخرى هنا udts ، لكنني أعتقد أن لديهم بعض الاستخدامات المذهلة. قامت PostgreSQL بالبحث الكامل في النص كمكون إضافي يعتمد على UDTS لفترة طويلة قبل أن يتم دمج البحث في النص الكامل بالفعل في المنتج الأساسي. في الوقت الحالي ، يعد PostGIS منتج GIS ناجحًا جدًا وهو مكون إضافي بالكامل يعتمد على UDTS (يحتوي على ترخيص GPL ، لذلك لن يتم دمجه أبدًا في Core).