2011-09-24 22 views
5

¿Cómo crear uno a muchos en SQLITE3? Tengo 2 tablas:¿Cómo crear uno a muchos en SQLITE3?

Mans: 
_id name 
1 antony 
2 fred 

y

point 
_id date point 
1  23  77 
     24  99 

2  25  78 
     5  0 

No sé sintaxis SQL, que me ayude, por favor.

+0

Dudo que la segunda tabla sea así: ¿estas tablas SQL o los datos que desea ingresar? – Mark

+0

Esa es la segunda mesa –

Respuesta

3

La sintaxis para esto es la siguiente ....

CREATE TABLE (MySecondTable) Foo INT FOREIGN KEY(Foo) REFERENCES MyFirstTable(PrimaryKeyField) ON DELETE CASCASDE ON UPDATE CASCASDE 

sólo funciona en v3.6.1 +

Éstos son los documentos http://sqlite.org/foreignkeys.html

+0

villano de illin shrimp-skrillin: ¿has verificado mi respuesta? –

11

A juzgar por lo que iamkrillin la camarones- illin skrillin villano:

CREATE TABLE (points) points_id INT 
FOREIGN KEY(man_id) REFERENCES mans(PrimaryKeyField) 
ON DELETE CASCASDE ON UPDATE CASCASDE 

Aquí hay un ejemplo del mundo real. Digamos que tiene algunas personas que le recomiendan negocios: su personal, sus amigos, empresas locales donde hace publicidad, etc. Los clientes que entran se llaman negocios 'referal'. Cada persona solo cuenta como un referal, pero un referer puede referir muchos referals (por ejemplo, un empleado puede referir a 20 nuevos clientes, el empleado es su referencia, y el empleado ha hecho 20 referals). Por lo tanto, usted tiene 1 árbitro y 20 Referals (uno-a-muchos):

CREATE TABLE referal(           
    referal_id INTEGER UNIQUE NOT NULL PRIMARY KEY,   //A customer can only be 1 referal. 
    referal_method TEXT,          //How were they refered? By phone? 
    referer_id INTEGER ,          //Who refered them? 
    FOREIGN KEY(referer_id) REFERENCES referer(referer_id)); //Trace more about referer. 

Ahora, es posible que más de una persona se refiere a referal, pero creo que es una práctica estándar de negocios sólo a compensar un solo referer. Entonces, nunca necesita listar dos referencias. Esta siempre será una relación de 1 a 1 o de 1 a muchos; por lo tanto, debe hacer que sea una tabla de uno a muchos. No soy muy competente en CASCADE, pero intentaré descubrir cómo encaja.

A primera vista, parece que ON UPDATE CASCADE ON DELETE CASCADE no pertenece a mi respuesta, ya que la eliminación del último referal no debería eliminar al responsable.

Mirando a a different example:

CREATE TABLE all_candy 
    (candy_num SERIAL PRIMARY KEY, 
    candy_maker CHAR(25)); 

CREATE TABLE hard_candy 
    (candy_num INT, 
    candy_flavor CHAR(20), 
    FOREIGN KEY (candy_num) REFERENCES all_candy 
    ON DELETE CASCADE) 

Si elimina un caramelo duro de la mesa hard_candy, entonces también está eliminando de la mesa all_candy porque un caramelo duro es un tipo de dulce, y si el tipo de de caramelos ha cambiado (por ejemplo, a los dulces descontinuados), entonces un nuevo comando INSERT debe ser ejecutado, de todos modos.

Ejecuté un caso de prueba para ON UPDATE CASCADE y ON UPDATE DELETE en sqlite3, y parece que no tiene ningún efecto. Tal vez no funcionen con el motor db predeterminado para sqlite3, pero la funcionalidad SE figura en el sitio web oficial de SQLite: a very descriptive, easy-to-follow example of ON UPDATE CASCADE by sqlite.org. Lea y vea lo que piensa.

Este es el esquema que utilicé para mi caso de prueba:

BEGIN TRANSACTION; 
CREATE TABLE candy(id integer primary key not null, name text, description text); 
INSERT INTO candy VALUES(1,'Laffy Taffy', 'Delicious, soft candy.'); 
INSERT INTO candy VALUES(2,'Pop Rocks', 'A candy that explodes in your mouth.'); 
COMMIT; 

BEGIN TRANSACTION; 
CREATE TABLE hard_candy(id integer primary key not null, name text, description text, foreign key(id,name,description) references hard_candy ON DELETE CASCADE ON UPDATE CASCADE); 
INSERT INTO hard_candy VALUES(2,'Pop Rocks', 'A candy that explodes in your mouth.'); 
COMMIT; 

Ran varias actualizaciones en campo de descripción id-2 de cualquiera de las tablas.

Cuestiones relacionadas