ProHoster > Blog > Administración > Equilibrar escrituras e lecturas nunha base de datos

Equilibrar escrituras e lecturas nunha base de datos

Equilibrar escrituras e lecturas nunha base de datos
No anterior Artigo Describín o concepto e implementación dunha base de datos construída sobre a base de funcións, en lugar de táboas e campos como nas bases de datos relacionais. Proporcionou moitos exemplos que mostran as vantaxes deste enfoque fronte ao clásico. Moitos consideraron que non eran o suficientemente convincentes.

Neste artigo, mostrarei como este concepto permítelle equilibrar de xeito rápido e cómodo as escrituras e as lecturas na base de datos sen ningún cambio na lóxica de funcionamento. Tentouse implementar unha funcionalidade semellante nos DBMS comerciais modernos (en particular, Oracle e Microsoft SQL Server). Ao final do artigo demostrarei que o que fixeron, por dicilo suavemente, non resultou moi ben.

Descrición

Como antes, para unha mellor comprensión comezarei a descrición con exemplos. Digamos que necesitamos implementar unha lóxica que devolverá unha lista de departamentos co número de empregados neles e o seu salario total.

Nunha base de datos funcional sería así:

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);

A complexidade de executar esta consulta en calquera DBMS será equivalente a O (número de empregados)porque este cálculo require escanear toda a táboa de empregados e agrupalos despois por departamentos. Tamén haberá algún pequeno complemento (cremos que hai moitos máis empregados que departamentos) dependendo do plan elixido O (número de rexistro de empregados) ou O (número de departamentos) para agrupar, etc.

Está claro que a sobrecarga de execución pode ser diferente en diferentes DBMS, pero a complexidade non cambiará de ningún xeito.

Na implementación proposta, o DBMS funcional xerará unha subconsulta que calculará os valores necesarios para o departamento e, a continuación, realizará un JOIN coa táboa do departamento para obter o nome. Non obstante, para cada función, ao declarar, é posible establecer un marcador especial MATERIALIZADO. O sistema creará automaticamente un campo correspondente para cada función. Ao cambiar o valor dunha función, o valor do campo tamén cambiará na mesma transacción. Ao acceder a esta función, accederase ao campo precalculado.

En particular, se configura MATERIALIZADO para funcións contarEmpleados и salarioSuma, entón engadiranse dous campos á táboa coa lista de departamentos, que almacenará o número de empregados e o seu salario total. Sempre que se produza un cambio nos empregados, nos seus salarios ou afiliacións ao departamento, o sistema cambiará automaticamente os valores destes campos. A consulta anterior accederá directamente a estes campos e executarase en O (número de departamentos).

Cales son as restricións? Só unha cousa: tal función debe ter un número finito de valores de entrada para os que se define o seu valor. En caso contrario, será imposible construír unha táboa que almacene todos os seus valores, xa que non pode haber unha táboa con un número infinito de filas.

Exemplo:

employeesCount ‘Количество сотрудников с зарплатой > N’ (Department d, NUMERIC[10,2] N) = 
    GROUP SUM salary(Employee e) IF department(e) = d AND salary(e) > N;

Esta función defínese para un número infinito de valores do número N (por exemplo, calquera valor negativo é adecuado). Polo tanto, non podes poñerlle MATERIALIZADO. Polo tanto, esta é unha limitación lóxica, non técnica (é dicir, non porque non puidésemos implementala). En caso contrario, non hai restricións. Podes usar agrupacións, ordenación, AND e OU, PARTICIÓN, recursión, etc.

Por exemplo, no problema 2.2 do artigo anterior, pode poñer MATERIALIZADO en ambas funcións:

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;

O propio sistema creará unha táboa con claves de tipo Cliente, Produto и INTEGRAL, engadiralle dous campos e actualizará os valores de campo neles con calquera cambio. Cando se fagan máis chamadas a estas funcións, non se calcularán, senón que leranse os valores dos campos correspondentes.

Usando este mecanismo, pode, por exemplo, desfacerse das recursións (CTE) nas consultas. En particular, considere os grupos que forman unha árbore usando a relación fillo/pai (cada grupo ten unha ligazón ao seu pai):

parent = DATA Group (Group);

Nunha base de datos funcional, a lóxica de recursión pódese especificar do seguinte xeito:

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;

Xa que para a función é o pai está marcado MATERIALIZADO, entón crearase unha táboa con dúas claves (grupos) para ela, na que o campo é o pai só será verdadeira se a primeira clave é filla da segunda. O número de entradas nesta táboa será igual ao número de grupos multiplicado pola profundidade media da árbore. Se precisa, por exemplo, contar o número de descendentes dun determinado grupo, pode utilizar esta función:

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

Non haberá CTE na consulta SQL. En cambio, haberá un sinxelo GROUP BY.

Usando este mecanismo, tamén pode desnormalizar facilmente a base de datos se é necesario:

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

CLASS OrderDetail 'Строка заказа';
order 'Заказ' = DATA Order (OrderDetail);
date 'Дата' (OrderDetail d) = date(order(d)) MATERIALIZED INDEXED;

Ao chamar a unha función data para a liña de pedido, o campo para o que hai un índice lerase da táboa con liñas de orde. Cando cambie a data do pedido, o propio sistema volverá calcular automaticamente a data desnormalizada na liña.

Vantaxes

Para que serve todo este mecanismo? Nos DBMS clásicos, sen reescribir as consultas, un desenvolvedor ou DBA só pode cambiar índices, determinar estatísticas e indicarlle ao planificador de consultas como executalas (e as suxestións só están dispoñibles nos DBMS comerciais). Por moito que se esforcen, non poderán completar a primeira consulta do artigo en O (número de departamentos) sen cambiar as consultas nin engadir disparadores. No esquema proposto, na fase de desenvolvemento non tes que pensar na estrutura de almacenamento de datos e que agregacións usar. Todo isto pódese cambiar facilmente sobre a marcha, directamente en funcionamento.

Na práctica parécese así. Algunhas persoas desenvolven a lóxica directamente baseándose na tarefa a realizar. Non entenden os algoritmos e a súa complexidade, nin os plans de execución, nin os tipos de unións, nin ningún outro compoñente técnico. Estas persoas son máis analistas empresariais que desenvolvedores. Despois, todo isto pasa a ser probado ou operativo. Permite o rexistro de consultas de longa duración. Cando se detecta unha consulta longa, outras persoas (máis técnicas, esencialmente DBA) deciden activar MATERIALIZED nalgunha función intermedia. Isto ralentiza un pouco a gravación (xa que require actualizar un campo adicional na transacción). Non obstante, non só esta consulta se acelera significativamente, senón tamén todas as outras que usan esta función. Ao mesmo tempo, decidir que función materializar é relativamente fácil. Dous parámetros principais: o número de valores de entrada posibles (este é o número de rexistros na táboa correspondente) e a frecuencia con que se usa noutras funcións.

Analóxicos

Os DBMS comerciais modernos teñen mecanismos semellantes: VISTA MATERIALIZADA con REFRESH RÁPIDO (Oracle) e VISTA INDIDADA (Microsoft SQL Server). En PostgreSQL, MATERIALIZED VIEW non se pode actualizar nunha transacción, senón só a petición (e mesmo con restricións moi estritas), polo que non o consideramos. Pero teñen varios problemas que limitan significativamente o seu uso.

En primeiro lugar, só podes activar a materialización se xa creaches unha VIEW normal. En caso contrario, terás que reescribir as solicitudes restantes para acceder á vista recentemente creada para utilizar esta materialización. Ou deixalo todo como está, pero será polo menos ineficaz se hai certos datos xa precalculados, pero moitas consultas non sempre os usan, senón que os recalculan.

En segundo lugar, teñen unha gran cantidade de restricións:

oráculo

5.3.8.4 Restricións xerais sobre a actualización rápida

A consulta de definición da vista materializada está restrinxida do seguinte xeito:

  • A vista materializada non debe conter referencias a expresións que non se repiten como SYSDATE ROWNUM.
  • A vista materializada non debe conter referencias a RAW or LONG RAW tipos de datos.
  • Non pode conter a SELECT subconsulta de lista.
  • Non pode conter funcións analíticas (por exemplo, RANK) En SELECT cláusula.
  • Non pode facer referencia a unha táboa na que un XMLIndex índice está definido.
  • Non pode conter a MODEL cláusula.
  • Non pode conter a HAVING cláusula cunha subconsulta.
  • Non pode conter consultas aniñadas que teñan ANY, ALLou NOT EXISTS.
  • Non pode conter a [START WITH …] CONNECT BY cláusula.
  • Non pode conter varias táboas de detalles en sitios diferentes.
  • ON COMMIT As vistas materializadas non poden ter táboas de detalles remotos.
  • As vistas materializadas anidadas deben ter unha unión ou un agregado.
  • Vistas unidas materializadas e vistas agregadas materializadas con a GROUP BY a cláusula non pode seleccionar dunha táboa organizada por índices.

5.3.8.5 Restricións na actualización rápida en vistas materializadas só con unións

A definición de consultas para vistas materializadas só con unións e sen agregados ten as seguintes restricións na actualización rápida:

  • Todas as restricións de «Restricións xerais sobre a actualización rápida«.
  • Non poden ter GROUP BY cláusulas ou agregados.
  • Filas de todas as táboas do FROM debe aparecer na lista SELECT lista da consulta.
  • Os rexistros de vista materializada deben existir con filas para todas as táboas base do FROM lista da consulta.
  • Non pode crear unha vista materializada que se actualice rapidamente a partir de varias táboas con uniones simples que inclúan unha columna de tipo de obxecto no SELECT declaración.

Ademais, o método de actualización que escolla non será óptimamente eficiente se:

  • A consulta de definición usa unha unión externa que se comporta como unha unión interna. Se a consulta de definición contén unha unión deste tipo, considere reescribir a consulta de definición para que conteña unha unión interna.
  • o SELECT A lista da vista materializada contén expresións en columnas de varias táboas.

5.3.8.6 Restricións na actualización rápida en vistas materializadas con agregados

A definición de consultas para vistas materializadas con agregados ou unións ten as seguintes restricións na actualización rápida:

A actualización rápida é compatible con ambos ON COMMIT ON DEMAND vistas materializadas, non obstante, aplícanse as seguintes restricións:

  • Todas as táboas da vista materializada deben ter rexistros de vista materializada e os rexistros de vista materializada deben:
    • Contén todas as columnas da táboa á que se fai referencia na vista materializada.
    • Especificar con ROWID INCLUDING NEW VALUES.
    • especifique o SEQUENCE cláusula se se espera que a táboa teña unha mestura de insercións/cargas directas, eliminacións e actualizacións.

  • Só SUM, COUNT, AVG, STDDEV, VARIANCE, MIN MAX son compatibles para unha actualización rápida.
  • COUNT(*) debe especificarse.
  • As funcións agregadas deben aparecer só como a parte máis externa da expresión. É dicir, agregados como AVG(AVG(x)) or AVG(x)+ AVG(x) non están permitidos.
  • Para cada agregado como AVG(expr), o correspondente COUNT(expr) debe estar presente. Oracle recomenda iso SUM(expr) ser especificado.
  • If VARIANCE(expr) or STDDEV(expr) se especifica, COUNT(expr) SUM(expr) debe especificarse. Oracle recomenda iso SUM(expr *expr) ser especificado.
  • o SELECT a columna da consulta de definición non pode ser unha expresión complexa con columnas de varias táboas base. Unha posible solución para isto é usar unha vista materializada aniñada.
  • o SELECT a lista debe conter todas GROUP BY columnas.
  • A vista materializada non se basea nunha ou máis táboas remotas.
  • Se usa un CHAR tipo de datos nas columnas de filtro dun rexistro de vista materializada, os conxuntos de caracteres do sitio mestre e da vista materializada deben ser os mesmos.
  • Se a vista materializada ten un dos seguintes, entón a actualización rápida só se admite nas insercións DML convencionais e nas cargas directas.
    • Vistas materializadas con MIN or MAX agregados
    • Vistas materializadas que teñen SUM(expr) pero non COUNT(expr)
    • Vistas materializadas sen COUNT(*)

    A dita vista materializada denomínase vista materializada de só inserción.

  • Unha visión materializada con MAX or MIN pódese actualizar rapidamente despois de borrar ou mesturar declaracións DML se non ten un WHERE cláusula.
    A actualización rápida máx./min despois da eliminación ou DML mesturado non ten o mesmo comportamento que o caso de só inserción. Elimina e volve calcular os valores máximos/min para os grupos afectados. Debe ser consciente do seu impacto no rendemento.
  • Vistas materializadas con vistas nomeadas ou subconsultas no FROM a cláusula pódese actualizar rapidamente sempre que as vistas se poidan combinar completamente. Para obter información sobre as vistas que se combinarán, consulte Referencia da linguaxe SQL da base de datos Oracle.
  • Se non hai unións externas, pode ter seleccións e unións arbitrarias no WHERE cláusula.
  • As vistas agregadas materializadas con unións externas pódense actualizar rapidamente despois de cargas directas e DML convencionais, sempre que só se modifique a táboa exterior. Ademais, deben existir restricións únicas nas columnas de unión da táboa de unión interna. Se hai unións externas, todas as unións deben estar conectadas por ANDs e debe utilizar a igualdade (=) operador.
  • Para vistas materializadas con CUBE, ROLLUP, conxuntos de agrupación ou concatenación deles, aplícanse as seguintes restricións:
    • o SELECT A lista debe conter un distintivo de agrupación que pode ser a GROUPING_ID función en todos GROUP BY expresións ou GROUPING funcións unha para cada unha GROUP BY expresión. Por exemplo, se o GROUP BY a cláusula da vista materializada é "GROUP BY CUBE(a, b)", entón o SELECT a lista debe conter "GROUPING_ID(a, b)» ou «GROUPING(a) AND GROUPING(b)» para que a vista materializada se poida actualizar rapidamente.
    • GROUP BY non debería dar lugar a agrupacións duplicadas. Por exemplo, "GROUP BY a, ROLLUP(a, b)" non se pode actualizar rapidamente porque dá lugar a agrupacións duplicadas "(a), (a, b), AND (a)«.

5.3.8.7 Restricións na actualización rápida en vistas materializadas con UNION ALL

Vistas materializadas co UNION ALL establecer o soporte do operador REFRESH FAST opción se se cumpren as seguintes condicións:

  • A consulta de definición debe ter o UNION ALL operador no nivel superior.

    o UNION ALL O operador non se pode incrustar nunha subconsulta, cunha excepción: The UNION ALL pode estar nunha subconsulta no FROM cláusula sempre que a consulta definitoria sexa da forma SELECT * FROM (ver ou subconsulta con UNION ALL) como no seguinte exemplo:

    CREATE VIEW view_with_unionall AS (SELECT c.rowid crid, c.cust_id, 2 umarker FROM clientes c WHERE c.cust_last_name = 'Smith' UNION ALL SELECT c.rowid crid, c.cust_id, 3 umarker FROM clientes c WHERE c.cust_last_name 'Jones'); CREAR VISUALIZACIÓN MATERIALIZADA unionall_inside_view_mv ACTUALIZAR RÁPIDO A PETICIÓN COMO SELECCIONE * FROM view_with_unionall;

    Teña en conta que a vista view_with_unionall cumpre os requisitos para a actualización rápida.

  • Cada bloque de consulta no UNION ALL a consulta debe satisfacer os requisitos dunha vista materializada de actualización rápida con agregados ou dunha vista materializada de actualización rápida con combinacións.

    Deben crearse nas táboas os rexistros de vistas materializadas axeitados segundo sexa necesario para o tipo correspondente de vista materializada de actualización rápida.
    Teña en conta que a base de datos Oracle tamén permite o caso especial dunha única vista materializada de táboa con unións só sempre que o ROWID incluíuse na columna SELECT lista e no rexistro da vista materializada. Isto móstrase na consulta de definición da vista view_with_unionall.

  • o SELECT a lista de cada consulta debe incluír a UNION ALL marcador, e o UNION ALL columna debe ter un valor numérico ou de cadea distinto constante en cada unha UNION ALL rama. Ademais, a columna do marcador debe aparecer na mesma posición ordinal no SELECT lista de cada bloque de consulta. Ver "UNION ALL Marcador e reescritura de consultas» para máis información sobre UNION ALL marcadores.
  • Algunhas funcións, como as unións externas, as consultas de vistas materializadas agregadas de só inserción e as táboas remotas non son compatibles coas vistas materializadas con UNION ALL. Teña en conta, non obstante, que as vistas materializadas utilizadas na replicación, que non conteñen uniones ou agregados, pódense actualizar rapidamente cando UNION ALL ou utilízanse táboas remotas.
  • O parámetro de inicialización da compatibilidade debe establecerse en 9.2.0 ou superior para crear unha vista materializada que se actualice rápidamente con UNION ALL.

Non quero ofender aos fanáticos de Oracle, pero a xulgar pola súa lista de restricións, parece que este mecanismo non foi escrito no caso xeral, usando algún tipo de modelo, senón por miles de indios, onde todos tiñan a oportunidade de escribir a súa propia rama, e cada un deles fixo o que puido e fixo. Usar este mecanismo para a lóxica real é como camiñar por un campo minado. Podes conseguir unha mina en calquera momento golpeando unha das restricións non obvias. Como funciona tamén é unha cuestión separada, pero está fóra do alcance deste artigo.

Microsoft SQLServer

Requisitos adicionais

Ademais das opcións SET e dos requisitos de función determinista, deben cumprirse os seguintes requisitos:

  • O usuario que executa CREATE INDEX debe ser o propietario da vista.
  • Cando crea o índice, o IGNORE_DUP_KEY a opción debe estar desactivada (a configuración predeterminada).
  • As táboas deben estar referenciadas por nomes de dúas partes, esquema.nome da táboa na definición da vista.
  • As funcións definidas polo usuario ás que se fai referencia na vista deben crearse mediante o WITH SCHEMABINDING opción.
  • Calquera función definida polo usuario ás que se fai referencia na vista debe facerse referencia con nomes de dúas partes, ..
  • A propiedade de acceso a datos dunha función definida polo usuario debe ser NO SQL, e a propiedade de acceso externo debe ser NO.
  • As funcións de Common Language Runtime (CLR) poden aparecer na lista de selección da vista, pero non poden formar parte da definición da clave de índice agrupado. As funcións CLR non poden aparecer na cláusula WHERE da vista ou na cláusula ON dunha operación JOIN na vista.
  • As funcións CLR e os métodos dos tipos CLR definidos polo usuario utilizados na definición da vista deben ter as propiedades definidas como se mostra na seguinte táboa.

    Propiedade
    Nota

    DETERMINISTA = VERDADEIRO
    Debe declararse explícitamente como un atributo do método Microsoft .NET Framework.

    PRECISO = VERDADEIRO
    Debe declararse explícitamente como un atributo do método .NET Framework.

    ACCESO A DATOS = SIN SQL
    Determinado configurando o atributo DataAccess como DataAccessKind.None e o atributo SystemDataAccess como SystemDataAccessKind.None.

    ACCESO EXTERNO = NO
    Esta propiedade predeterminada é NO para as rutinas CLR.

  • A vista debe ser creada usando o WITH SCHEMABINDING opción.
  • A vista debe facer referencia só ás táboas base que estean na mesma base de datos que a vista. A vista non pode facer referencia a outras vistas.
  • A instrución SELECT na definición da vista non debe conter os seguintes elementos Transact-SQL:

    COUNT
    funcións ROWSET (OPENDATASOURCE, OPENQUERY, OPENROWSET, E OPENXML)
    OUTER xunta (LEFT, RIGHTou FULL)

    Táboa derivada (definida especificando a SELECT declaración no FROM cláusula)
    Autounións
    Especificación de columnas mediante SELECT * or SELECT <table_name>.*

    DISTINCT
    STDEV, STDEVP, VAR, VARPou AVG
    Expresión de táboa común (CTE)

    flotar1, texto, ntexto, imaxe, XMLou fluxo de ficheiros columnas
    subquery
    OVER cláusula, que inclúe funcións de xanela de clasificación ou agregado

    Predicados de texto completo (CONTAINS, FREETEXT)
    SUM función que fai referencia a unha expresión nula
    ORDER BY

    Función agregada CLR definida polo usuario
    TOP
    CUBE, ROLLUPou GROUPING SETS operadores

    MIN, MAX
    UNION, EXCEPTou INTERSECT operadores
    TABLESAMPLE

    Variables da táboa
    OUTER APPLY or CROSS APPLY
    PIVOT, UNPIVOT

    Conxuntos de columnas escasos
    Funcións en liña (TVF) ou con valores de táboa de varias sentencias (MSTVF)
    OFFSET

    CHECKSUM_AGG

    1 A vista indexada pode conter flotar columnas; non obstante, tales columnas non se poden incluír na clave de índice agrupado.

  • If GROUP BY está presente, a definición VIEW debe conter COUNT_BIG(*) e non debe conter HAVING. Estes GROUP BY as restricións só son aplicables á definición da vista indexada. Unha consulta pode usar unha vista indexada no seu plan de execución aínda que non as satisfaga GROUP BY restricións.
  • Se a definición da vista contén a GROUP BY cláusula, a clave do índice agrupado único pode facer referencia só ás columnas especificadas no GROUP BY cláusula.

Aquí está claro que os indios non participaron, xa que decidiron facelo segundo o esquema "faremos pouco, pero ben". É dicir, teñen máis minas no campo, pero a súa localización é máis transparente. O máis decepcionante é esta limitación:

A vista debe facer referencia só ás táboas base que estean na mesma base de datos que a vista. A vista non pode facer referencia a outras vistas.

Na nosa terminoloxía, isto significa que unha función non pode acceder a outra función materializada. Isto recorta toda ideoloxía no brote.
Ademais, esta limitación (e máis adiante no texto) reduce moito os casos de uso:

A instrución SELECT na definición da vista non debe conter os seguintes elementos Transact-SQL:

COUNT
funcións ROWSET (OPENDATASOURCE, OPENQUERY, OPENROWSET, E OPENXML)
OUTER xunta (LEFT, RIGHTou FULL)

Táboa derivada (definida especificando a SELECT declaración no FROM cláusula)
Autounións
Especificación de columnas mediante SELECT * or SELECT <table_name>.*

DISTINCT
STDEV, STDEVP, VAR, VARPou AVG
Expresión de táboa común (CTE)

flotar1, texto, ntexto, imaxe, XMLou fluxo de ficheiros columnas
subquery
OVER cláusula, que inclúe funcións de xanela de clasificación ou agregado

Predicados de texto completo (CONTAINS, FREETEXT)
SUM función que fai referencia a unha expresión nula
ORDER BY

Función agregada CLR definida polo usuario
TOP
CUBE, ROLLUPou GROUPING SETS operadores

MIN, MAX
UNION, EXCEPTou INTERSECT operadores
TABLESAMPLE

Variables da táboa
OUTER APPLY or CROSS APPLY
PIVOT, UNPIVOT

Conxuntos de columnas escasos
Funcións en liña (TVF) ou con valores de táboa de varias sentencias (MSTVF)
OFFSET

CHECKSUM_AGG

OUTER JOINS, UNION, ORDER BY e outros están prohibidos. Quizais fose máis doado especificar o que se podía usar en lugar de o que non se podía usar. A lista probablemente sería moito máis curta.

Para resumir: un conxunto enorme de restricións en todos os DBMS (nótese comercialmente) fronte a ningún (a excepción dun lóxico, non técnico) na tecnoloxía LGPL. Porén, hai que ter en conta que implementar este mecanismo na lóxica relacional é algo máis difícil que na lóxica funcional descrita.

Implantación

Cómo funciona? PostgreSQL úsase como unha "máquina virtual". Dentro hai un algoritmo complexo que crea consultas. Aquí fonte. E non hai só un gran conxunto de heurísticas cunha morea de ifs. Así que, se tes un par de meses para estudar, podes tentar entender a arquitectura.

Funciona eficazmente? Bastante eficaz. Desafortunadamente, isto é difícil de demostrar. Só podo dicir que se tes en conta os miles de consultas que existen en grandes aplicacións, de media son máis eficientes que as dun bo programador. Un excelente programador de SQL pode escribir calquera consulta de forma máis eficiente, pero con mil consultas simplemente non terá a motivación nin o tempo para facelo. O único que agora podo citar como proba de eficacia é que varios proxectos están a traballar na plataforma construída sobre este DBMS Sistemas ERP, que teñen miles de funcións MATERIALIZADAS diferentes, con miles de usuarios e bases de datos de terabytes con centos de millóns de rexistros executados nun servidor normal de dous procesadores. Non obstante, calquera pode comprobar/refutar a eficacia descargando plataforma e PostgreSQL, acendendo rexistrando consultas SQL e intentando cambiar alí a lóxica e os datos.

Nos artigos seguintes, falarei tamén de como podes establecer restricións nas funcións, traballar con sesións de cambio e moito máis.

Fonte: www.habr.com

Engadir un comentario