Oda a SQL Server

Leo en Phil Factor que su autor pretende escribir un libro sobre SQL Server en verso… Nos adelanta una oda a los índices de una base de datos SQL Server…

¡A ver si la literatura me ayuda a aprobar bases de datos de una vez!

The Index: An Elegy

(I have always wondered why nobody has written a book on SQL Server in verse. To correct this lamentable gap in the market, I have been penning some stanzas.
Here, as a sample, is a short verse on indexing)

An index is used as a short-cut to data
a table will warrant one sooner or later
Because only one can be clustered, beware
and ponder the index you cluster with care
the issues are clearer than you might suppose
this index determines the order of rows
so searching the index requires less I/O.
Selecting the column on which it should go
depends on the way that the rows are selected,
which should become clear if the Schema’s inspected.
One problem, however, I think you should know,
retrieving a range can be horribly slow.

A non-clustered index is almost as good
once ordering keys can be well understood
make sure that the columns you use are selective
for if too few values, it’s most ineffective
if data is changing or updating too
with frequent insertions, keep indexes few.
from 2000 on you can index a view
(but then there’s restrictions on what you can do)
and even on computed columns as well
but only if deterministic as hell
For reasons which often are misunderstood
a non-clustered covering index is good
when composite columns are used with some care
they outperform anything else that’s out there

Acceso a la información de las tablas de una base de datos Access

El amigo Luis, que está sacando gran partido a las bases de datos Access según me cuentan (espero que pronto lo muestre), me preguntaba hoy que si conocía alguna manera de acceder a los datos acerca de las tablas en una base de datos Access. Tenía una ligera idea de por dónde iban los tiros (MSysObjects), y, tras investigar un poco, a continuación paso a enumerar las sentencias necesarias para acceder a diversa información:

Número de tablas de usuario:

SELECT COUNT(*)
FROM msysobjects
WHERE (((msysobjects.Type)=1) AND ((msysobjects.Flags)=0));

Nombre de todas las tablas de usuario:

SELECT msysobjects.Name
FROM msysobjects
WHERE (((msysobjects.Type)=1) AND ((msysobjects.Flags)=0));

Número de formularios:

SELECT COUNT(*)
FROM msysobjects
WHERE (((msysobjects.Type)=-32768) AND ((msysobjects.Flags)=0));

Nombre de todos los formularios:

SELECT msysobjects.Name
FROM msysobjects
WHERE (((msysobjects.Type)=-32768) AND ((msysobjects.Flags)=0));

Número de consultas:

SELECT COUNT(*)
FROM msysobjects
WHERE (((msysobjects.Type)=5) AND ((msysobjects.Flags)=0));

Nombre de todas las consultas:

SELECT msysobjects.Name
FROM msysobjects
WHERE (((msysobjects.Type)=5) AND ((msysobjects.Flags)=0));

¿Preguntas? ¿Sugerencias? Usen los comentarios 🙂

Álgebra relacional

Es importante que antes de resolver los problemas en SQL se haya realizado un esfuerzo por comprender y resolver problemas parecidos utilizando álgebra relacional. El motivo de esto es que, una vez comprendidas las operaciones a realizar desde el punto de vista matemático, el paso a SQL será una labor prácticamente inmediata ya que se puede considerar al álgebra relacional como el ensamblador del SQL.

Capítulo 5 de Problemas de Bases de Datos. Luis Grau Fernández e Ignacio López Rodríguez.