كيف تعمل وجهات نظر MySQL؟

Question

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

أيضا لماذا لا يمكنني استخدام الفائزين الفرعيين في رأيي؟

Answer 1

عرض يعمل مثل الجدول, ، لكنها ليست طاولة. لا يوجد أبدا. إنه مجرد عبارة SQL المعدة يتم تشغيلها عند الرجوع إلى اسم العرض. بمعنى آخر:

CREATE VIEW foo AS
  SELECT * FROM bar

SELECT * FROM foo

... يعادل الجري:

SELECT x.* 
  FROM (SELECT * FROM bar) x

لن يحتوي mysqldump أبدًا على صفوف لإدراجها في عرض ...

أيضا لماذا لا يمكنني استخدام الفائقين في رأيي ؟؟؟؟

هذا ، للأسف ، هو (وإن كان مشكوك فيه) التصميم. هناك قيود عديدة على وجهات نظر MySQL ، والتي تم توثيقها: http://dev.mysql.com/doc/refman/5.0/en/create-view.html

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

---

رقم.
يمكن أن يحتوي الجدول على فهارس مرتبطة ، والتي يمكن أن تجعل استرجاع البيانات أسرع (بتكلفة بعض التكلفة لإدراج/تحديث). تدعم بعض قواعد البيانات وجهات نظر "ملموسة" ، والتي هي طرق عرض يمكن أن تكون لها فهارس مطبقة عليها - والتي لا ينبغي أن تكون مفاجأة أن MySQL لا يدعم بالنظر إلى وظائف الرؤية المحدودة (التي بدأت فقط في V5 IIRC ، متأخرة جدًا في اللعبة).

نظرًا لأن العرض عبارة عن جدول مشتق ، فإن أداء العرض جيد تمامًا مثل الاستعلام الذي تم بناؤه. إذا تمتص هذا الاستعلام ، فستكون مشكلة الأداء مجرد كرة الثلج ... ومع ذلك ، عند الاستعلام عن طريقة عرض - إذا لم يتم لف العمود عرض عرض في الفقرة في وظيفة (أي: على سبيل المثال: WHERE v.column LIKE ..., ليس WHERE LOWER(t.column) LIKE ...) ، قد يدفع المحسن المعايير (يسمى مسند) على الاستعلام الأصلي - مما يجعله أسرع.

Answer 2

واجهت نفس المشكلة أيضًا (لدهشتي ، لأن بحثي يبدو أنه يشير إلى أن Oracle و MS يدعمانها).

أتجول في هذا القيد (على الأقل في الوقت الحالي ، حتى يثبت أنه غير قابل للاستخدام) من خلال إنشاء عرضين إضافيين لرؤيتي النهائية.

مثال:

CREATE VIEW Foo1 AS
    SELECT * FROM t ORDER BY ID, InsertDate DESC

CREATE VIEW Foo2 AS
    SELECT * FROM Foo1 GROUP BY ID

CREATE VIEW Foo AS
    SELECT * FROM Foo2 ORDER BY ID

يحتوي المثال أعلاه بشكل أساسي على جدول "T" وهو جدول زمني يحتوي على جميع المراجعات. إن "Foo" (عرض) في الأساس هو رؤية بسيطة لأحدث مراجعاتي الحالية لكل سجل. يبدو أنه يعمل بشكل جيد الآن!

تحديث:

لا أعرف ما إذا كان هذا خطأ آخر في MySQL 5.1 ، لكن المثال أعلاه لا يعمل في الواقع! يعمل "FOO1" كما هو متوقع ، ولكن يبدو أن "FOO2" يتجاهل الترتيب قبل التجميع ، لذا فإن نتيجتي النهائية ليست ما هو مقصود. حتى أنني أحصل على نفس النتيجة إذا قمت بتغيير "DESC" لـ "ASC" (بشكل مدهش).

أيضا ، إذا قرأت 17.5.1. عرض بناء الجملة القسم ، ينص بوضوح:

"يمكن إنشاء طريقة عرض من أنواع كثيرة من عبارات الاختيار. يمكن أن تشير إلى الجداول الأساسية أو غيرها من المشاهدات. يمكنه استخدام الوصول والاتحاد والحرّايات الفرعية."

سأقوم بتحديث قاعدة البيانات الخاصة بي إلى 5.6 وجربها مرة أخرى!

Answer 3

والفرق هو :

للعرض ، يمكنك فقط أن يكون لديك خواص فرعية في مكان - الجزء ، وليس في الجزء من - لذلك أ

CREATE VIEW v AS SELECT * FROM foo WHERE id IN (SELECT id FROM bar) 

ستعمل - ولكن في نفس الوقت تحصل على عرض للقراءة فقط ... عرض بسيط على جدول واحد يسمح بالتحديث "من خلال" العرض إلى الجدول الأساسي