Claves Primarias Compuestas

Las claves primarias pueden ser simples, formadas por un solo campo o compuestas, más de un
campo.
Recordemos que una clave primaria identifica 1 solo registro en una tabla.
Para un valor del campo clave existe solamente 1 registro. Los valores no se repiten ni pueden
ser nulos.
Existe una playa de estacionamiento que almacena cada día los datos de los vehículos que
ingresan en la tabla llamada "vehiculos" con los siguientes campos:
- patente char(6) not null,
- tipo char (1), 'a'= auto, 'm'=moto,
- horallegada datetime,
- horasalida datetime,
Necesitamos definir una clave primaria para una tabla con los datos descriptos arriba. No
podemos usar solamente la patente porque un mismo auto puede ingresar más de una vez en el
día a la playa; tampoco podemos usar la hora de entrada porque varios autos pueden ingresar a
una misma hora.
Tampoco sirven los otros campos.
Como ningún campo, por si sólo cumple con la condición para ser clave, es decir, debe
identificar un solo registro, el valor no puede repetirse, debemos usar 2 campos.
Definimos una clave compuesta cuando ningún campo por si solo cumple con la condición para
ser clave.
En este ejemplo, un auto puede ingresar varias veces en un día a la playa, pero siempre será a
distinta hora.
Usamos 2 campos como clave, la patente junto con la hora de llegada, así identificamos
unívocamente cada registro.
Para establecer más de un campo como clave primaria usamos la siguiente sintaxis:
create table vehiculos(
patente char(6) not null,
tipo char(1),--'a'=auto, 'm'=moto
horallegada datetime,
horasalida datetime,
primary key(patente,horallegada)
);
Nombramos los campos que formarán parte de la clave separados por comas.
Al ingresar los registros, SQL Server controla que los valores para los campos establecidos
como clave primaria no estén repetidos en la tabla; si estuviesen repetidos, muestra un mensaje
y la inserción no se realiza. Lo mismo sucede si realizamos una actualización.
Entonces, si un solo campo no identifica unívocamente un registro podemos definir una clave
primaria compuesta, es decir formada por más de un campo.

Índices
Un índice es una estructura de datos que permite acceder a diferentes filas de una misma tabla a
través de un campo (o campos clave).
Un índice permite un acceso mucho más rápido a los datos.

Creación de índices
CREATE INDEX;
DROP INDEX;
Sintaxis para la creacion
CREATE [UNIQUE] INDEX <nombre_indice>
ON <nombre_tabla>(
<nombre_campo> [ASC | DESC]
 {,<nombre_campo> [ASC | DESC]})
);
La pálabra clave UNIQUE especifica que que no pueden existir claves duplicadas en el índice.
ASC | DESC especifican el criterio de ordenación elegido, ascendente o descendente, por
defecto es ascendente.

Tablas Autoreferenciadas

Self Referencing Tables In SQL Server

With the increasing complexity of tasks we require from our databases, there is an increasing
demand for data structure flexibility. Here is one solution I have found to be very useful. I have
lifted a working 'Self referencing table with trigger materialized view' straight out of a working
project and explained how it functions:
Step 1: The tables

In the above example we can see the Location table (Locn) the Location Type (LocnType) and
Location Parent Table (LocnPrnt). This is a classic self referencing challenge. The point being
that locations are inherently hierarchical. Westminster is in London which is in England; but,
Cowley is in Oxford which is also in England; hence Cowley and Westminster are both in
England.
Step 2: What is self referencing and parent/child
Traditional database techniques can handle this if the number of levels of referencing is known
and limited. Once can create a country table, a town table and a district table. But, what happens
then if locations need more layers? The solution is to make the table self referencing and to
remove the type of location from the table definition. Instead of having a County table, we have
records in the Location table of type 'County'. Then, we store the fact that Cowley is in Oxford
but making the the Parent identifier of Cowley the Location Identifier for Oxford.
For some people (me included) the first time one comes across this idea, making rows know
their parent (as compared to letting rows know their children) seems counter intuitive. However,
this structure allows totally flexibility as to the number of children a row can have so is the
correct way around.
Step 3: Creating a recursive scalar function (mimicking 'connect by')
Great, but how do we answer the question 'is Cowley in England'. If we have our Country,
County, Town, District type structure, it is a simple table join. Using nested SQL we could join
Location to its self, however we do not know up front how many levels of Parent/Child
relationships lie between Cowley and England. Is it England/Oxfordshire/Oxford/Cowley or
England/Oxford/Cowley. To maintain the flexibility, we need a way of answering the question
that is always correct irrespective of the number of levels. Oracle does this for us with the
'Connect By' clause. Here is a simple recursive scalar function which does the same thing in
SQL Server:
-- If Locn is LocnIsOrPrnt or
-- if Locn is a disendent of LocnIsOrPrnt it returns
-- -1 otherwise it returns 0
CREATE FUNCTION [dbo].[F_LocnIsOrPrnt]
(
@Locn BIGINT,
@LocnIsOrPrnt BIGINT
)
RETURNS SMALLINT
AS
BEGIN
DECLARE @Ret SMALLINT
DECLARE @Prnt BIGINT
SET @Ret=0
IF @Locn IS NULL or @LocnIsOrPrnt IS NULL
BEGIN
SET @Ret=0
RETURN @Ret
END
IF @Locn=@LocnIsOrPrnt
BEGIN
SET @Ret=-1
RETURN @Ret
END
SELECT @Prnt=Prnt FROM T_Locn WHERE LocnId=@Locn
IF @Prnt=@LocnIsOrPrnt
BEGIN
SET @Ret=-1
RETURN @Ret
END
IF @Prnt=@Locn
BEGIN
SET @Ret=0
RETURN @Ret
END
SET @Ret=dbo.F_LocnIsOrPrnt(@Prnt,@LocnIsOrPrnt)
RETURN @Ret
END

MySQL historia

Empezamos con la intención de usar mSQL para conectar a nuestras tablas utilizando nuestras
propias rutinas rápidas de bajo nivel (ISAM). Sin embargo y tras algunas pruebas, llegamos a la
conclusión que mSQL no era lo suficientemente rápido o flexible para nuestras necesidades.
Esto provocó la creación de una nueva interfaz SQL para nuestra base de datos pero casi con la
misma interfaz API que mSQL. Esta API fue diseñada para permitir código de terceras partes
que fue escrito para poder usarse con mSQL para ser fácilmente portado para el uso con
MySQL.
La derivación del nombre MySQL no está clara. Nuestro directorio base y un gran número de
nuestras bibliotecas y herramientas han tenido el prefijo "my" por más de 10 años. Sin embargo,
la hija del co-fundador Monty Widenius también se llama My. Cuál de los dos dió su nombre a
MySQL todavía es un misterio, incluso para nosotros.
El nombre del delfín de MySQL (nuestro logo) es "Sakila", que fué elegido por los fundadores
de MySQL AB de una gran lista de nombres sugerida por los usuarios en el concurso "Name the
Dolphin" (ponle nombre al delfín). El nombre ganador fue enviado por Ambrose Twebaze, un
desarrollador de software Open Source de Swaziland, África. Según Ambrose, el nombre
femenino de Sakila tiene sus raíces en SiSwate, el idioma local de Swaziland. Sakila también es
el nombre de una ciudad en Arusha, Tanzania, cerca del país de origen de Ambrose, Uganda.
Tipos de Engine y Tablas
MySQL soporta varios motores de almacenamiento que tratan con distintos tipos de tabla. Los
motores de almacenamiento de MySQL incluyen algunos que tratan con tablas transaccionales y
otros que no lo hacen:
MyISAM trata tablas no transaccionales. Proporciona almacenamiento y recuperación de datos
rápida, así como posibilidad de búsquedas fulltext. MyISAM se soporta en todas las
configuraciones MySQL, y es el motor de almacenamiento por defecto a no ser que tenga una
configuración distinta a la que viene por defecto con MySQL.
El motor de almacenamiento MEMORY proporciona tablas en memoria. El motor de
almacenamiento MERGE permite una colección de tablas MyISAM idénticas ser tratadas como
una simple tabla. Como MyISAM, los motores de almacenamiento MEMORY y MERGE tratan
tablas no transaccionales y ambos se incluyen en MySQL por defecto.
Nota: El motor de almacenamiento MEMORY anteriormente se conocía como HEAP.
Los motores de almacenamiento InnoDB y BDB proporcionan tablas transaccionales. BDB se
incluye en la distribución binaria MySQL-Max en aquellos sistemas operativos que la soportan.
InnoDB también se incluye por defecto en todas las distribuciones binarias de MySQL 5.0 . En
distribuciones fuente, puede activar o desactivar estos motores de almacenamiento configurando
MySQL a su gusto.
El motor de almacenamiento EXAMPLE es un motor de almacenamiento "tonto" que no hace
nada. Puede crear tablas con este motor, pero no puede almacenar datos ni recuperarlos. El
objetivo es que sirva como ejemplo en el código MySQL para ilustrar cómo escribir un motor
de almacenamiento. Como tal, su interés primario es para desarrolladores.
NDB Cluster es el motor de almacenamiento usado por MySQL Cluster para implementar tablas
que se particionan en varias máquinas. Está disponible en distribuciones binarias MySQL-Max
5.0. Este motor de almacenamiento está disponible para Linux, Solaris, y Mac OS X .
Añadiremos soporte para este motor de almacenamiento en otras plataformas, incluyendo
Windows en próximas versiones.
El motor de almacenamiento ARCHIVE se usa para guardar grandes cantidades de datos sin
índices con una huella muy pequeña.
El motor de almacenamiento CSV guarda datos en ficheros de texto usando formato de valores
separados por comas.
El motor de almacenamiento FEDERATED se añadió en MySQL 5.0.3. Este motor guarda
datos en una base de datos remota. En esta versión sólo funciona con MySQL a través de la API
MySQL C Client. En futuras versiones, será capaz de conectar con otras fuentes de datos
usando otros drivers o métodos de conexión clientes.
6.- JOIN

La sentencia JOIN en SQL permite combinar registros de dos o más tablas en una base de datos
relacional. En el Lenguaje de Consultas Estructurado (SQL), hay tres tipo de JOIN: interno,
externo, y cruzado.
En casos especiales una tabla puede unirse a sí misma, produciendo una auto-combinación,
SELF-JOIN.
Combinación interna : Con esta operación se calcula el producto cruzado de todos los registros;
así cada registro en la tabla A es combinado con cada registro de la tabla B; pero sólo
permanecen aquellos registros en la tabla combinada que satisfacen las condiciones que se
especifiquen. Este es el tipo de JOIN más utilizado por lo que es considerado el tipo de
combinación predeterminado.

De equivalencia (equi-join)
Es una especie de theta-join que usa comparaciones de igualdad en el predicado JOIN. Cuando
se usan operadores, tales como < o > no se puede clasificar en este rango.
Natural (Natural join)
Es una especialización de la combinación de equivalencia, anteriormente mencionada. En este
caso se comparan todas las columnas que tengan el mismo nombre en ambas tablas. La tabla
resultante contiene sólo una columna por cada par de columnas con el mismo nombre.
Cruzada (Cross join)
Presenta el producto cartesiano de todos los registros de las dos tablas.
El código SQL para realizar este producto cartesiano enuncia las tablas que serán combinadas,
pero no incluye algún predicado que filtre el resultado.
Combinación externa (OUTER JOIN) : Mediante esta operación no se requiere que cada
registro en las tablas a tratar tenga un registro equivalente en la otra tabla. El registro es
mantenido en la tabla combinada si no existe otro registro que le corresponda.

7.- acciones referenciales

CASCADE Whenever rows in the master (referenced) table are deleted, the respective rows of
the child (referencing) table with a matching foreign key column will get deleted as well. This is
called a cascade delete.
RESTRICT A value cannot be updated or deleted when a row exists in a foreign key table that
references the value in the referenced table.
NO ACTION NO ACTION and RESTRICT are very much alike. The main difference between
NO ACTION and RESTRICT is that with NO ACTION the referential integrity check is done
after trying to alter the table. RESTRICT does the check before trying to execute the UPDATE
or DELETE statement. Both referential actions act the same if the referential integrity check
fails: the UPDATE or DELETE statement will result in an error.
SET NULL The foreign key values in the referencing row are set to NULL when the referenced
row is updated or deleted.
SET DEFAULT Similarly to SET NULL, the foreign key values in the referencing row are set
to the column default when the referenced row is updated or deleted.