プロホスト > ブログ > 行政 > デヌタベヌスでの曞き蟌みず読み取りのバランスを取る

デヌタベヌスでの曞き蟌みず読み取りのバランスを取る

デヌタベヌスでの曞き蟌みず読み取りのバランスを取る
前に статье リレヌショナル デヌタベヌスのようなテヌブルやフィヌルドではなく、関数に基づいお構築されたデヌタベヌスの抂念ず実装に぀いお説明したした。 埓来のアプロヌチに比べおこのアプロヌチの利点を瀺す倚くの䟋が提䟛されたした。 倚くの人は、それらは十分に説埗力がないず感じたした。

この蚘事では、この抂念により、操䜜ロゞックを倉曎するこずなく、デヌタベヌスぞの曞き蟌みず読み取りのバランスを迅速か぀䟿利に実珟できる方法を説明したす。 同様の機胜が、最新の商甚 DBMS (特に Oracle および Microsoft SQL Server) に実装されるこずが詊みられおいたす。 この蚘事の最埌では、圌らがやったこずは、控えめに蚀っおもあたりうたくいかなかったこずを瀺したす。

説明

前ず同様に、理解を深めるために、䟋を挙げお説明を始めたす。 たずえば、郚門のリストずその郚門の埓業員数ずその合蚈絊䞎を返すロゞックを実装する必芁があるずしたす。

機胜デヌタベヌスでは次のようになりたす。

CLASS Department â€˜ÐžÑ‚Ўел’;
name â€˜ÐÐ°ÐžÐŒÐµÐœÐŸÐ²Ð°ÐœÐžÐµâ€™ = DATA STRING[100] (Department);

CLASS Employee â€˜Ð¡ÐŸÑ‚руЎМОк’;
department â€˜ÐžÑ‚Ўел’ = DATA Department (Employee);
salary â€˜Ð—арплата’ =  DATA NUMERIC[10,2] (Employee);

countEmployees â€˜ÐšÐŸÐ»-вП ÑÐŸÑ‚Ñ€ÑƒÐŽÐœÐžÐºÐŸÐ²â€™ (Department d) = 
    GROUP SUM 1 IF department(Employee e) = d;
salarySum â€˜Ð¡ÑƒÐŒÐŒÐ°Ñ€ÐœÐ°Ñ Ð·Ð°Ñ€Ð¿Ð»Ð°Ñ‚а’ (Department d) = 
    GROUP SUM salary(Employee e) IF department(e) = d;

SELECT name(Department d), countEmployees(d), salarySum(d);

DBMS でこのク゚リを実行する耇雑さは、次ず同等になりたす。 O(埓業員数)なぜなら、この蚈算では埓業員の衚党䜓をスキャンしおから郚門ごずにグルヌプ化する必芁があるからです。 遞択したプランに応じお、小芏暡な埓業員の数が郚門よりもはるかに倚いず思われたす远加料金も発生したす。 O(埓業員数のログ) たたは O(郚門の数) グルヌプ化などに。

実行オヌバヌヘッドが DBMS ごずに異なる可胜性があるこずは明らかですが、耇雑さはたったく倉わりたせん。

提案された実装では、機胜 DBMS は郚門に必芁な倀を蚈算する XNUMX ぀のサブク゚リを生成し、郚門テヌブルず JOIN を䜜成しお名前を取埗したす。 ただし、関数ごずに、宣蚀時に特別な MATERIALIZED マヌカヌを蚭定するこずができたす。 システムは、そのような関数ごずに察応するフィヌルドを自動的に䜜成したす。 関数の倀を倉曎するず、同じトランザクション内でフィヌルドの倀も倉曎されたす。 この関数にアクセスするず、事前蚈算されたフィヌルドにアクセスしたす。

特に、関数に MATERIALIZED を蚭定した堎合 埓業員数 О 絊䞎合蚈, 次に、郚門のリストを含む XNUMX ぀のフィヌルドがテヌブルに远加され、埓業員の数ずその合蚈絊䞎が保存されたす。 埓業員、絊䞎、所属郚門に倉曎があるず、システムはこれらのフィヌルドの倀を自動的に倉曎したす。 䞊蚘のク゚リはこれらのフィヌルドに盎接アクセスし、次のように実行されたす。 O(郚門の数).

制限事項は䜕ですか? 唯䞀のこずは、そのような関数は、その倀が定矩される有限数の入力倀を持たなければならないずいうこずです。 そうしないず、無限の行数を持぀テヌブルは存圚できないため、すべおの倀を栌玍するテヌブルを構築するこずができなくなりたす。

䟋

employeesCount â€˜ÐšÐŸÐ»ÐžÑ‡ÐµÑÑ‚вП ÑÐŸÑ‚руЎМОкПв Ñ Ð·Ð°Ñ€Ð¿Ð»Ð°Ñ‚Пй > N’ (Department d, NUMERIC[10,2] N) = 
    GROUP SUM salary(Employee e) IF department(e) = d AND salary(e) > N;

この関数は、無限の N の倀に察しお定矩されたす (たずえば、任意の負の倀が適しおいたす)。 したがっお、MATERIALIZED を眮くこずはできたせん。 したがっお、これは論理的な制限であり、技術的な制限ではありたせん (぀たり、実装できなかったためではありたせん)。 それ以倖の堎合は制限はありたせん。 グルヌプ化、䞊べ替え、AND ず OR、PARTITION、再垰などを䜿甚できたす。

たずえば、前の蚘事の問題 2.2 では、䞡方の関数に MATERIALIZED を蚭定できたす。

bought 'КупОл' (Customer c, Product p, INTEGER y) = 
    GROUP SUM sum(Detail d) IF 
        customer(order(d)) = c AND 
        product(d) = p AND 
        extractYear(date(order(d))) = y MATERIALIZED;
rating 'РейтОМг' (Customer c, Product p, INTEGER y) = 
    PARTITION SUM 1 ORDER DESC bought(c, p, y), p BY c, y MATERIALIZED;
SELECT contactName(Customer c), name(Product p) WHERE rating(c, p, 1997) < 3;

システム自䜓がタむプキヌを持぀ XNUMX ぀のテヌブルを䜜成したす。 顧客, プロダクト О 敎数、それに XNUMX ぀のフィヌルドを远加し、倉曎があればそれらのフィヌルド倀を曎新したす。 これらの関数ぞのさらなる呌び出しが行われるず、それらは蚈算されず、察応するフィヌルドから倀が読み取られたす。

このメカニズムを䜿甚するず、たずえば、ク゚リ内の再垰 (CTE) を取り陀くこずができたす。 特に、子/芪関係を䜿甚しおツリヌを圢成するグルヌプを考慮したす (各グルヌプにはその芪ぞのリンクがありたす)。

parent = DATA Group (Group);

機胜デヌタベヌスでは、再垰ロゞックは次のように指定できたす。

level (Group child, Group parent) = RECURSION 1l IF child IS Group AND parent == child
                                                             STEP 2l IF parent == parent($parent);
isParent (Group child, Group parent) = TRUE IF level(child, parent) MATERIALIZED;

機胜のため 芪です MATERIALIZED ずマヌクされおいる堎合、XNUMX ぀のキヌ (グルヌプ) を持぀テヌブルが䜜成されたす。 芪です 最初のキヌが XNUMX 番目のキヌの子の堎合にのみ true になりたす。 このテヌブル内の゚ントリの数は、グルヌプの数にツリヌの平均深さを乗算したものに等しくなりたす。 たずえば、特定のグルヌプの子孫の数を数える必芁がある堎合は、次の関数を䜿甚できたす。

childrenCount (Group g) = GROUP SUM 1 IF isParent(Group child, g);

SQL ク゚リには CTE はありたせん。 代わりに、単玔な GROUP BY がありたす。

このメカニズムを䜿甚するず、必芁に応じおデヌタベヌスを簡単に非正芏化するこずもできたす。

CLASS Order 'Заказ';
date 'Дата' = DATA DATE (Order);

CLASS OrderDetail 'СтрПка Ð·Ð°ÐºÐ°Ð·Ð°';
order 'Заказ' = DATA Order (OrderDetail);
date 'Дата' (OrderDetail d) = date(order(d)) MATERIALIZED INDEXED;

関数を呌び出すずき date 泚文明现の堎合、むンデックスがあるフィヌルドが泚文明现のあるテヌブルから読み取られたす。 泚文日が倉曎されるず、システム自䜓が明现行の非正芏化された日付を自動的に再蚈算したす。

利点

この仕組み党䜓は䜕のためにあるのでしょうか? 埓来の DBMS では、ク゚リを曞き換えるこずなく、開発者たたは DBA はむンデックスを倉曎し、統蚈を決定し、それらの実行方法をク゚リ プランナに指瀺するこずしかできたせん (HINT は商甚 DBMS でのみ䜿甚できたす)。 どんなに頑匵っおも、蚘事の最初のク゚リを完了するこずはできたせん。 O (郚門の数) ク゚リを倉曎したりトリガヌを远加したりする必芁はありたせん。 提案されたスキヌムでは、開発段階でデヌタ ストレヌゞ構造やどの集蚈を䜿甚するかを考える必芁はありたせん。 これらはすべお、操䜜䞭に盎接、その堎で簡単に倉曎できたす。

実際にはこんな感じになりたす。 目の前のタスクに盎接基づいおロゞックを開発する人もいたす。 圌らは、アルゎリズムずその耇雑さ、実行蚈画、結合の皮類、その他の技術コンポヌネントを理解しおいたせん。 これらの人々は開発者ずいうよりもビゞネス アナリストです。 その埌、これらすべおがテストたたは運甚に入りたす。 長時間実行されるク゚リのログを有効にしたす。 長いク゚リが怜出されるず、他の人 (より技術的な - 本質的には DBA) が、䜕らかの䞭間関数で MATERIALIZED を有効にするこずを決定したす。 これにより、蚘録が少し遅くなりたす (トランザクション内の远加フィヌルドを曎新する必芁があるため)。 ただし、このク゚リだけでなく、この関数を䜿甚する他のすべおのク゚リも倧幅に高速化されたす。 同時に、どの機胜を実珟するかを決定するこずは比范的簡単です。 XNUMX ぀の䞻なパラメヌタ: 可胜な入力倀の数 (これは、察応するテヌブルに含たれるレコヌドの数です)、および他の関数で䜿甚される頻床です。

類䌌䜓

最新の商甚 DBMS には、FAST REFRESH を備えた MATERIALIZED VIEW (Oracle) および INDEXED VIEW (Microsoft SQL Server) など、同様のメカニズムがありたす。 PostgreSQL では、MATERIALIZED VIEW はトランザクション内で曎新できず、芁求に応じおのみ曎新できたす (さらに非垞に厳しい制限がありたす)。そのため、考慮しおいたせん。 しかし、それらには、その䜿甚を倧幅に制限するいく぀かの問題がありたす。

たず、マテリアラむれヌションを有効にできるのは、通垞の VIEW をすでに䜜成しおいる堎合のみです。 それ以倖の堎合は、この具䜓化を䜿甚するために新しく䜜成されたビュヌにアクセスするために残りのリク゚ストを曞き盎す必芁がありたす。 たたは、すべおをそのたたにしおおきたすが、すでに事前に蚈算された特定のデヌタがあり、倚くのク゚リで垞にそれが䜿甚されるわけではなく、再蚈算される堎合には、少なくずも効果はありたせん。

第二に、膚倧な数の制限がありたす。

オラクル

5.3.8.4 高速リフレッシュに関する䞀般的な制限事項

マテリアラむズド ビュヌの定矩ク゚リは次のように制限されたす。

  • マテリアラむズド ビュヌには、次のような非繰り返し匏ぞの参照が含たれおいおはなりたせん。 SYSDATE & ROWNUM.
  • マテリアラむズド ビュヌには、ぞの参照が含たれおいおはなりたせん。 RAW or LONG RAW デヌタ型。
  • を含めるこずはできたせん SELECT リストサブク゚リ。
  • 分析関数を含めるこずはできたせん (たずえば、 RANK の䞭に SELECT 句。
  • が含たれるテヌブルを参照するこずはできたせん。 XMLIndex むンデックスが定矩されおいたす。
  • を含めるこずはできたせん MODEL 句。
  • を含めるこずはできたせん HAVING サブク゚リを含む句。
  • 次のようなネストされたク゚リを含めるこずはできたせん。 ANY, ALLたたは NOT EXISTS.
  • を含めるこずはできたせん [START WITH 
] CONNECT BY 句。
  • 異なるサむトにある耇数の詳现テヌブルを含めるこずはできたせん。
  • ON COMMIT マテリアラむズド ビュヌにはリモヌト詳现テヌブルを含めるこずはできたせん。
  • ネストされたマテリアラむズド ビュヌには結合たたは集蚈が必芁です。
  • マテリアラむズド結合ビュヌずマテリアラむズド集玄ビュヌ GROUP BY 句は玢匕構成衚から遞択できたせん。

5.3.8.5 結合のみを䜿甚したマテリアラむズド・ビュヌでの高速リフレッシュの制限

結合のみを䜿甚し、集蚈を䜿甚しないマテリアラむズド ビュヌのク゚リを定矩するず、高速リフレッシュに関しお次の制限がありたす。

  • « からのすべおの制限高速リフレッシュに関する䞀般的な制限事項"
  • 圌らは持぀こずができない GROUP BY 句たたは集合䜓。
  • 内のすべおのテヌブルのROWID FROM リストは SELECT ク゚リのリスト。
  • マテリアラむズド・ビュヌ・ログは、すべおの実衚のROWIDずずもに存圚する必芁がありたす。 FROM ク゚リのリスト。
  • オブゞェクト型列を含む単玔な結合を䜿甚する耇数のテヌブルから高速リフレッシュ可胜なマテリアラむズド ビュヌを䜜成するこずはできたせん。 SELECT 声明。

たた、次の堎合、遞択した曎新方法は最適な効率を発揮したせん。

  • 定矩ク゚リは、内郚結合ず同様に動䜜する倖郚結合を䜿甚したす。 定矩ク゚リにそのような結合が含たれおいる堎合は、内郚結合を含むように定矩ク゚リを曞き盎すこずを怜蚎しおください。
  • 　 SELECT マテリアラむズド ビュヌのリストには、耇数のテヌブルの列に関する匏が含たれおいたす。

5.3.8.6 集蚈を䜿甚したマテリアラむズド・ビュヌの高速リフレッシュの制限

集蚈たたは結合を䜿甚したマテリアラむズド ビュヌのク゚リを定矩する堎合、高速リフレッシュに関しお次の制限がありたす。

高速リフレッシュは䞡方でサポヌトされおいたす ON COMMIT & ON DEMAND ただし、次の制限が適甚されたす。

  • マテリアラむズド ビュヌ内のすべおのテヌブルにはマテリアラむズド ビュヌ ログが必芁であり、マテリアラむズド ビュヌ ログは次の条件を満たす必芁がありたす。
    • マテリアラむズド ビュヌで参照されるテヌブルのすべおの列が含たれたす。
    • で指定したす ROWID & INCLUDING NEW VALUES.
    • 特定したす SEQUENCE テヌブルに挿入/盎接ロヌド、削陀、曎新が混圚するこずが予想される堎合は、この句を䜿甚したす。

  • のみ SUM, COUNT, AVG, STDDEV, VARIANCE, MIN & MAX 高速リフレッシュがサポヌトされおいたす。
  • COUNT(*) 指定する必芁がありたす。
  • 集蚈関数は、匏の最も倖偎の郚分ずしおのみ䜿甚する必芁がありたす。 ぀たり、次のような集合䜓です。 AVG(AVG(x)) or AVG(x)+ AVG(x) 蚱可されおいたせん。
  • 次のような各集蚈に぀いお AVG(expr)、 察応したす COUNT(expr) 存圚する必芁がありたす。 オラクルは次のこずを掚奚しおいたす SUM(expr) 指定されるこず。
  • If VARIANCE(expr) or STDDEV(expr) が指定され、 COUNT(expr) & SUM(expr) を指定する必芁がありたす。 オラクルは次のこずを掚奚しおいたす SUM(expr *expr) 指定されるこず。
  • 　 SELECT 定矩ク゚リ内の列は、耇数のベヌス テヌブルの列を含む耇雑な匏にするこずはできたせん。 これに察する可胜な回避策は、ネストされたマテリアラむズド ビュヌを䜿甚するこずです。
  • 　 SELECT リストにはすべおが含たれおいる必芁がありたす GROUP BY 列。
  • マテリアラむズド ビュヌは XNUMX ぀以䞊のリモヌト テヌブルに基づいおいたせん。
  • あなたが䜿甚しおいる堎合 CHAR マテリアラむズド・ビュヌ・ログのフィルタ列のデヌタ型を䜿甚するには、マスタヌ・サむトずマテリアラむズド・ビュヌの文字セットが同じである必芁がありたす。
  • マテリアラむズド・ビュヌに次のいずれかがある堎合、高速リフレッシュは埓来の DML 挿入および盎接ロヌドでのみサポヌトされたす。
    • マテリアラむズドビュヌ MIN or MAX 骚材
    • マテリアラむズド ビュヌ SUM(expr) でもない COUNT(expr)
    • マテリアラむズドビュヌなし COUNT(*)

    このようなマテリアラむズド ビュヌは、挿入専甚マテリアラむズド ビュヌず呌ばれたす。

  • マテリアラむズドビュヌ MAX or MIN 削陀たたは混合 DML ステヌトメントの埌に、 WHERE 句。
    削陀たたは混合 DML 埌の最倧/最小高速リフレッシュは、挿入のみの堎合ず同じ動䜜をしたせん。 圱響を受けるグルヌプの最倧倀/最小倀を削陀しお再蚈算したす。 パフォヌマンスぞの圱響を認識する必芁がありたす。
  • 名前付きビュヌたたはサブク゚リを含むマテリアラむズド ビュヌ FROM ビュヌを完党にマヌゞできれば、句をすぐにリフレッシュできたす。 どのビュヌがマヌゞされるかに぀いおは、を参照しおください。 『Oracle Database SQL蚀語リファレンス』.
  • 倖郚結合がない堎合は、任意の遞択ず結合が可胜です。 WHERE 句。
  • 倖郚結合を䜿甚したマテリアラむズド集蚈ビュヌは、倖郚テヌブルのみが倉曎されおいれば、埓来の DML および盎接ロヌド埌に高速リフレッシュ可胜です。 たた、内郚結合テヌブルの結合列には䞀意制玄が存圚する必芁がありたす。 倖郚結合がある堎合は、すべおの結合を次の方法で接続する必芁がありたす。 ANDs であり、等䟡性 (=) 挔算子。
  • マテリアラむズドビュヌの堎合 CUBE, ROLLUP、グルヌプ化セット、たたはそれらの連結には、次の制限が適甚されたす。
    • 　 SELECT リストにはグルヌプ化識別子が含たれおいる必芁がありたす。 GROUPING_ID すべおに機胜する GROUP BY 衚珟や GROUPING それぞれに XNUMX ぀の機胜 GROUP BY 衚珟。 たずえば、 GROUP BY マテリアラむズドビュヌの句は「GROUP BY CUBE(a, b)"、 そうしお SELECT リストには次のいずれかを含める必芁がありたす。GROUPING_ID(a, b)" たた "GROUPING(a) AND GROUPING(b)» マテリアラむズド ビュヌを高速に曎新できるようにしたす。
    • GROUP BY 重耇したグルヌプ化が発生しないようにする必芁がありたす。 䟋えば、 "GROUP BY a, ROLLUP(a, b)" グルヌプ化が重耇するため、高速に曎新できたせん。"(a), (a, b), AND (a)"

5.3.8.7 UNION ALLを䜿甚したマテリアラむズド・ビュヌの高速リフレッシュの制限事項

マテリアラむズド ビュヌ UNION ALL セット挔算子のサポヌト REFRESH FAST 次の条件が満たされる堎合のオプション:

  • 定矩ク゚リには、 UNION ALL 最䞊䜍のオペレヌタ。

    　 UNION ALL 挔算子は、次の XNUMX ぀の䟋倖を陀いお、サブク゚リ内に埋め蟌むこずはできたせん。 UNION ALL のサブク゚リに含めるこずができたす FROM 定矩ク゚リが次の圢匏である堎合の句 SELECT * FROM (ビュヌたたはサブク゚リ UNION ALL) 次の䟋のように:

    CREATE VIEW view_with_unionall AS (SELECT c.rowid crid, c.cust_id, 2 umark FROM埗意先 c WHERE c.cust_last_name = 'Smith' UNION ALL SELECT c.rowid crid, c.cust_id, 3 umark FROM埗意先c WHERE c.cust_last_name = 「ゞョヌンズ」); MATERIALIZED VIEW を䜜成 Unionall_inside_view_mv SELECT * FROM view_with_unionall; ずしおオンデマンドで高速曎新したす。

    ビュヌに泚意しおください view_with_unionall 高速リフレッシュの芁件を満たしたす。

  • の各ク゚リ ブロック UNION ALL ク゚リは、集玄を䜿甚した高速リフレッシュ可胜なマテリアラむズド ビュヌ、たたは結合を䜿甚した高速リフレッシュ可胜なマテリアラむズド ビュヌの芁件を満たす必芁がありたす。

    察応するタむプの高速リフレッシュ可胜なマテリアラむズド・ビュヌの必芁に応じお、適切なマテリアラむズド・ビュヌ・ログを衚に䜜成する必芁がありたす。
    Oracle デヌタベヌスでは、結合を䜿甚した単䞀テヌブルのマテリアラむズド ビュヌずいう特殊なケヌスも蚱可されおいるこずに泚意しおください。 ROWID コラムが掲茉されたした SELECT リストおよびマテリアラむズド・ビュヌ・ログ内。 これはビュヌの定矩ク゚リに瀺されおいたす view_with_unionall.

  • 　 SELECT 各ク゚リのリストには、 UNION ALL マヌカヌず、 UNION ALL 列には、それぞれに個別の定数倀たたは文字列倀が必芁です。 UNION ALL 支店。 さらに、マヌカヌ列は、 SELECT 各ク゚リブロックのリスト。 芋る "UNION ALL マヌカヌずク゚リ リラむト» 詳现に぀いおは、 UNION ALL マヌカヌ
  • 倖郚結合、挿入専甚の集玄マテリアラむズド・ビュヌ・ク゚リヌ、リモヌト衚などの䞀郚の機胜は、次のマテリアラむズド・ビュヌではサポヌトされおいたせん。 UNION ALL。 ただし、結合や集蚈を含たないレプリケヌションで䜿甚されるマテリアラむズド ビュヌは、次の堎合に高速リフレッシュできるこずに泚意しおください。 UNION ALL たたはリモヌトテヌブルが䜿甚されたす。
  • 高速リフレッシュ可胜なマテリアラむズド・ビュヌを䜜成するには、互換性初期化パラメヌタを 9.2.0 以降に蚭定する必芁がありたす。 UNION ALL.

Oracle ファンを怒らせる぀もりはありたせんが、圌らの制限リストから刀断するず、このメカニズムはある皮のモデルを䜿甚しお䞀般的なケヌスではなく、䜕千人ものむンド人によっお曞かれたようであり、そこでは誰もがそれを行う機䌚が䞎えられおいたした。自分のブランチを䜜成し、それぞれができる限りのこずを行い、実際に実行したした。 このメカニズムを実際のロゞックに䜿甚するこずは、地雷原を歩くようなものです。 明癜ではない制限のいずれかに該圓するこずで、い぀でも地雷を取埗できたす。 それがどのように機胜するかに぀いおも別の問題ですが、この蚘事の範囲を超えおいたす。

Microsoft SQL サヌバヌ

远加芁件

SET オプションず決定論的関数の芁件に加えお、次の芁件を満たす必芁がありたす。

  • 実行するナヌザヌ CREATE INDEX ビュヌの所有者である必芁がありたす。
  • むンデックスを䜜成するず、 IGNORE_DUP_KEY オプションは OFF (デフォルト蚭定) に蚭定する必芁がありたす。
  • テヌブルは XNUMX ぀の郚分からなる名前で参照する必芁がありたす。 スキヌマ.テヌブル名 ビュヌ定矩で。
  • ビュヌで参照されるナヌザヌ定矩関数は、 WITH SCHEMABINDING オプションを遞択したす。
  • ビュヌ内で参照されるナヌザヌ定矩関数は、XNUMX ぀の郚分からなる名前で参照する必芁がありたす。 ..
  • ナヌザヌ定矩関数のデヌタ アクセス プロパティは次のずおりである必芁がありたす。 NO SQL、倖郚アクセス プロパティは次のずおりである必芁がありたす。 NO.
  • 共通蚀語ランタむム (CLR) 関数はビュヌの遞択リストに衚瀺できたすが、クラスタヌ化むンデックス キヌの定矩の䞀郚にするこずはできたせん。 CLR 関数は、ビュヌの WHERE 句たたはビュヌ内の JOIN 操䜜の ON 句には䜿甚できたせん。
  • ビュヌ定矩で䜿甚される CLR 関数ず CLR ナヌザヌ定矩型のメ゜ッドには、次の衚に瀺すようにプロパティが蚭定されおいる必芁がありたす。

    プロパティ
    Note

    決定的 = 真
    Microsoft .NET Framework メ゜ッドの属性ずしお明瀺的に宣蚀する必芁がありたす。

    正確 = 真
    .NET Framework メ゜ッドの属性ずしお明瀺的に宣蚀する必芁がありたす。

    デヌタアクセス = SQL なし
    DataAccess 属性を DataAccessKind.None に蚭定し、SystemDataAccess 属性を SystemDataAccessKind.None に蚭定するこずによっお決定されたす。

    倖郚アクセス = いいえ
    CLR ルヌチンの堎合、このプロパティのデフォルトは NO です。

  • ビュヌは、 WITH SCHEMABINDING オプションを遞択したす。
  • ビュヌは、ビュヌず同じデヌタベヌス内にあるベヌステヌブルのみを参照する必芁がありたす。 ビュヌは他のビュヌを参照できたせん。
  • ビュヌ定矩内の SELECT ステヌトメントには、次の Transact-SQL 芁玠を含めるこずはできたせん。

    COUNT
    ROWSET 関数 (OPENDATASOURCE, OPENQUERY, OPENROWSET、ず OPENXML)
    OUTER 結合したす(LEFT, RIGHTたたは FULL)

    掟生テヌブル ( SELECT のステヌトメント FROM 句
    自己結合
    を䜿甚しお列を指定する SELECT * or SELECT <table_name>.*

    DISTINCT
    STDEV, STDEVP, VAR, VARPたたは AVG
    共通テヌブル匏 (CTE)

    フロヌト1, 큎띌우드 êž°ë°˜ AI/ML및 고성능 컎퓚팅을 통한 디지턞 튞윈의 Ʞ쎈 – Edward Hsu, Rescale CPO 많은 엔지니얎링 쀑심 Ʞ업에게 큎띌우드는 R&D디지턞 전환의 첫 닚계음 뿐입니닀. 큎띌우드 자원을 활용핎 엔지니얎링 팀의 제앜을 핎결하는 닚계륌 넘얎, 시뮬레읎션 욎영을 통합하고 최적화하며, 궁극적윌로는 몚덞 Ʞ반의 협업곌 의사 결정을 지원하여 신제품을 결정할 때 데읎터 êž°ë°˜ 엔지니얎링을 적용하고자 합니닀. Rescale은 읎러한 혁신을 돕Ʞ 위핎 컎퓚팅 추천 엔진, 통합 데읎터 팹뾌멭, 메타데읎터 ꎀ늬 등을 개발하고 있습니닀. 읎번 자늬륌 빌렀 비슈니슀 겜쟁력 제고륌 위한 디지턞 튞윈 및 디지턞 슀레드 전략 개발 방법에 대한 읞사읎튞륌 나누고자 합니닀. , ntext, 画像, XMLたたは ファむルストリヌム コラム
    サブク゚リヌ
    OVER ランク付けたたは集蚈りィンドり関数を含む句

    党文述語 (CONTAINS, FREETEXT)
    SUM NULL 蚱容匏を参照する関数
    ORDER BY

    CLR ナヌザヌ定矩の集蚈関数
    TOP
    CUBE, ROLLUPたたは GROUPING SETS 挔算子

    MIN, MAX
    UNION, EXCEPTたたは INTERSECT 挔算子
    TABLESAMPLE

    テヌブル倉数
    OUTER APPLY or CROSS APPLY
    PIVOT, UNPIVOT

    スパヌス列セット
    むンラむン (TVF) たたは耇数ステヌトメントのテヌブル倀関数 (MSTVF)
    OFFSET

    CHECKSUM_AGG

    1 むンデックス付きビュヌには次のものを含めるこずができたす。 フロヌト 列。 ただし、そのような列をクラスタヌ化むンデックス キヌに含めるこずはできたせん。

  • If GROUP BY が存圚する堎合、VIEW 定矩には次のものが含たれおいる必芁がありたす。 COUNT_BIG(*) を含めおはなりたせん HAVING。 これら GROUP BY 制限はむンデックス付きビュヌ定矩にのみ適甚されたす。 ク゚リは、これらを満たさない堎合でも、実行プランでむンデックス付きビュヌを䜿甚できたす。 GROUP BY 制限。
  • ビュヌ定矩に GROUP BY 句を䜿甚するず、䞀意のクラスタヌ化むンデックスのキヌは、句で指定された列のみを参照できたす。 GROUP BY 句。

ここで、むンディアンが関䞎しおいないこずは明らかです。なぜなら、圌らは「私たちは少ししかやらないが、うたくやろう」ずいう蚈画に埓っおそれを行うこずを決定したからです。 ぀たり、フィヌルドにはより倚くの地雷がありたすが、その䜍眮はより透明になりたす。 最も残念なのは、この制限です。

ビュヌは、ビュヌず同じデヌタベヌス内にあるベヌステヌブルのみを参照する必芁がありたす。 ビュヌは他のビュヌを参照できたせん。

私たちの甚語では、これは、関数が別の具䜓化された関数にアクセスできないこずを意味したす。 これはあらゆるむデオロギヌの芜を切り萜ずしたす。
たた、この制限 (および本文の詳现) により、䜿甚䟋が倧幅に枛少したす。

ビュヌ定矩内の SELECT ステヌトメントには、次の Transact-SQL 芁玠を含めるこずはできたせん。

COUNT
ROWSET 関数 (OPENDATASOURCE, OPENQUERY, OPENROWSET、ず OPENXML)
OUTER 結合したす(LEFT, RIGHTたたは FULL)

掟生テヌブル ( SELECT のステヌトメント FROM 句
自己結合
を䜿甚しお列を指定する SELECT * or SELECT <table_name>.*

DISTINCT
STDEV, STDEVP, VAR, VARPたたは AVG
共通テヌブル匏 (CTE)

フロヌト1, 큎띌우드 êž°ë°˜ AI/ML및 고성능 컎퓚팅을 통한 디지턞 튞윈의 Ʞ쎈 – Edward Hsu, Rescale CPO 많은 엔지니얎링 쀑심 Ʞ업에게 큎띌우드는 R&D디지턞 전환의 첫 닚계음 뿐입니닀. 큎띌우드 자원을 활용핎 엔지니얎링 팀의 제앜을 핎결하는 닚계륌 넘얎, 시뮬레읎션 욎영을 통합하고 최적화하며, 궁극적윌로는 몚덞 Ʞ반의 협업곌 의사 결정을 지원하여 신제품을 결정할 때 데읎터 êž°ë°˜ 엔지니얎링을 적용하고자 합니닀. Rescale은 읎러한 혁신을 돕Ʞ 위핎 컎퓚팅 추천 엔진, 통합 데읎터 팹뾌멭, 메타데읎터 ꎀ늬 등을 개발하고 있습니닀. 읎번 자늬륌 빌렀 비슈니슀 겜쟁력 제고륌 위한 디지턞 튞윈 및 디지턞 슀레드 전략 개발 방법에 대한 읞사읎튞륌 나누고자 합니닀. , ntext, 画像, XMLたたは ファむルストリヌム コラム
サブク゚リヌ
OVER ランク付けたたは集蚈りィンドり関数を含む句

党文述語 (CONTAINS, FREETEXT)
SUM NULL 蚱容匏を参照する関数
ORDER BY

CLR ナヌザヌ定矩の集蚈関数
TOP
CUBE, ROLLUPたたは GROUPING SETS 挔算子

MIN, MAX
UNION, EXCEPTたたは INTERSECT 挔算子
TABLESAMPLE

テヌブル倉数
OUTER APPLY or CROSS APPLY
PIVOT, UNPIVOT

スパヌス列セット
むンラむン (TVF) たたは耇数ステヌトメントのテヌブル倀関数 (MSTVF)
OFFSET

CHECKSUM_AGG

OUTER JOIN、UNION、ORDER BY などは犁止されおいたす。 䜕が䜿甚できないかよりも、䜕が䜿甚できるかを指定する方が簡単だったかも知れたせん。 リストはおそらくもっず短いものになるでしょう。

芁玄するず、LGPL テクノロゞには、すべおの (商甚であるこずに泚意しおください) DBMS に膚倧な制限があり、(論理的なものではなく XNUMX ぀の論理的なものを陀いお) 制限はありたせん。 ただし、このメカニズムをリレヌショナル ロゞックで実装するのは、説明した関数型ロゞックよりも若干難しいこずに泚意しおください。

具珟化

䜿い方 PostgreSQLは「仮想マシン」ずしお利甚されたす。 内郚にはク゚リを構築する耇雑なアルゎリズムがありたす。 ここ ゜ヌスコヌド。 そしお、倧量の if を含む倧芏暡なヒュヌリスティック セットだけが存圚するわけではありたせん。 したがっお、数か月の勉匷時間があれば、建築を理解するこずができたす。

それは効果的に機胜したすか かなり効果的です。 残念ながら、これを蚌明するのは困難です。 倧芏暡なアプリケヌションに存圚する䜕千ものク゚リを考慮するず、平均しお優れた開発者のク゚リよりも効率的であるずしか蚀えたせん。 優秀な SQL プログラマヌは、あらゆるク゚リをより効率的に䜜成できたすが、ク゚リが XNUMX 個もある堎合、それを実行するモチベヌションも時間もありたせん。 有効性の蚌拠ずしお今私が挙げられる唯䞀のこずは、いく぀かのプロゞェクトがこの DBMS 䞊に構築されたプラットフォヌム䞊で動䜜しおいるずいうこずです。 ERPシステムには、䜕千もの異なる MATERIALIZED 関数があり、数千のナヌザヌず数億のレコヌドを含むテラバむトのデヌタベヌスが通垞の XNUMX プロセッサ サヌバヌ䞊で実行されたす。 ただし、ダりンロヌドするこずで誰でも有効性を確認・反論するこずができたす。 プラットフォヌム およびPostgreSQL、 オン SQL ク゚リをログに蚘録し、そこにあるロゞックずデヌタを倉曎しようずしたす。

次の蚘事では、機胜の制限を蚭定する方法、倉曎セッションの操䜜方法などに぀いおも説明したす。

出所 habr.com

コメントを远加したす