Problema con campos autonuméricos

[cabron32]

hola. la situacion es la siguiente: tengo 2 tablas relacionadas en la misma BD (SQL Server 2000 ODBC), donde una se llama USUARIOS (id_usuario: autonumerico, nombre_usuario: varchar), y otra ALUMNOS (id_usuario: foreign key de usuarios.id_usuario), entonces al momento de ingresar nombre de usuario, el id_usuario se genera automaticamente en la BD al insertar datos en la tabla USUARIOS.

Los datos para ambas tablas se ingresan en el mismo formulario, y son insertados utilizando un script PHP que colocara los datos correspondientes al usuario en la tabla del mismo nombre (con un INSERT INTO USURIOS), y lo mismo para los datos del alumno (con otro INSERT INTO ALUMNOS).

El problema esta cuando quiero ingresar el mismo id_usuario en la tabla ALUMNOS, ya que es necesario para relacionar las 2 tablas mencionadas. Pero no tengo forma (a mi conocimiento ) de hacer eso.

Espero puedan entender y ayudarme con mi problema.
Desde ya gracias

[iislas]

Los campos AUTONUMERICOS (IDENTITY), no son recomendados para tablas que tendran DELETE (borrado de registros).

Puedes obtener el IDENTITY que te dio el primer insert con la funcon SCOPE_IDENTITY(), para hacer referencia a tu segundo insert

[cabron32]

Iniciado por iislas

Los campos AUTONUMERICOS (IDENTITY), no son recomendados para tablas que tendran DELETE (borrado de registros).

Puedes obtener el IDENTITY que te dio el primer insert con la funcon SCOPE_IDENTITY(), para hacer referencia a tu segundo insert

Muchas gracias, quedo funcionando...

[Teosanchez]

Hola Cabron32 (vaya nombrecito que has elegido).

A mi entender, hay un problema de diseño en tu base de datos y también de conocimiento sobre los autonuméricos.

Te explico:

Las tablas de una BD deben tener un campo que permita identificar los registros individualmente. Este campo normalmente no contiene información de la entidad representada en la tabla y solo se utiliza como clave primaria.
Estos campos se declaran como autonuméricos e identidad (IDENTITY).

La otra tabla (alumnos) también debería tener su propio campo identidad y un campo para mantener la relación entre las dos (por ejemplo id_usuario).

Así, puedes hacer cualquier operación de inserción, modificación o borrado en cualquiera de ellas con la única condición de hacerla en el orden adecuado.

Insertar: Primero en Usuario y luego en Alumno
Borrar: Primero en Alumno y luego en Usuario
------------------------------------------------------------------
Como no sé si me he explicado bien, ahí tienes un ejemplo del diseño (copia y pega en SQL Server)


CREATE TABLE [dbo].[Usuario](
[Id] [int] IDENTITY(1,1) NOT NULL,
[Nombre] [varchar](50) NULL,
CONSTRAINT [PK_Usuario] PRIMARY KEY CLUSTERED
(
[Id] ASC
)WITH (IGNORE_DUP_KEY = OFF) ON [PRIMARY]
) ON [PRIMARY]
END
GO

CREATE TABLE [dbo].[Alumno](
[Id] [int] IDENTITY(1,1) NOT NULL,
[Id_Usuario] [int] NULL,
[Campo2] [nchar](10) NULL,
CONSTRAINT [PK_Alumno] PRIMARY KEY CLUSTERED
(
[Id] ASC
)WITH (IGNORE_DUP_KEY = OFF) ON [PRIMARY]
) ON [PRIMARY]
GO
-----------------------------------------------------------------------------------


Si necesitas más ayuda sobre SQL Server no dudes en pedirla.


Saludos

[iislas]

Teosanchez, me permito disentir contigo:

Las tablas de una BD deben tener un campo que permita identificar los registros individualmente
R= Es totalmente correcto y el conjunto de campos se les conoce como PRIMARY KEY

Este campo normalmente no contiene información de la entidad representada en la tabla y solo se utiliza como clave primaria
R= Esto no es del todo cierto, las PRIMARY KEY, si pueden y deben ser informacion de la tabla o entidad

Estos campos se declaran como autonuméricos e identidad (IDENTITY).
R= NO, de hecho, los campos IDENTITY, no son recomendados para tablas que sufriran de DELETE o insercciones falsas.

La DRI es cuidada siempre por el motor de base de datos respaldandose en los CONSTRAINT's

[Valery-Net]

Estoy totalmente de acuerdo con iislas

[Andres95]

Yo tambien...



Saludos!