Insérer et supprimer des lignes dans un tableau PHP

Version imprimable

27/04/2024, 18h35
draidius

Insérer et supprimer des lignes dans un tableau PHP

Bonjour

J'ai fait un tableau PHP qui va aller chercher des données dans une base SLQ express

Je peux ajouter des nouvelles lignes et supprimer la dernière ligne sans problème via un formulaire php et son fichier de traitement.
Par contre je n'arrive pas à faire des insertions ou des suppressions sans que ne pose de problème dans la base car ce sont des ID auto incrémenté.

et même via un script purement SQL, cela me donne en suppression un trou dans les ID et quand je veux remettre une ligne cela me met un message d’erreur " violation **** " il faut désactiver un truc et le réactiver un après, d'autant que si je veux modifier la ligne par exemple 25, en réalité il faut indiquer l'ID 24...

Je ne sais pas si il y a déjà des scripts tous fait ou non pour résoudre mes deux problèmes, si c'est le cas, je suis preneur

exemple code SQL ligne 104 pour remettre une ligne supprimé

Citation:

SET IDENTITY_INSERT AttributionAbon ON;

INSERT INTO AttributionAbon (ID, Departutil, NomUtilisateur, NomOrdinateur, EnvSystem, NomLogiciel, VersLogiciel, NumBC, NumDeSerie, CleLicence, TypeIns, InfoActivation, DateFinAbon, NumTicket, Commentaire)
VALUES (104, 'Test', 'toto', 'pc01', 'Windows', 'test', '1', '001', 'test', '123456', 'Initial', 'N/A', '02022022', 'TCK0001', 'RAS');

SET IDENTITY_INSERT AttributionAbon OFF;

l'idéal serait lors de la suppression d'une ligne avoir toutes les ligne qui était supérieur à 104 de descendre d'une position.

Merci d'avance
27/04/2024, 20h07
Séb.

Citation:

je n'arrive pas à faire des insertions ou des suppressions sans que ne pose de problème dans la base car ce sont des ID auto incrémenté.
et même via un script purement SQL, cela me donne en suppression un trou dans les ID

Un ID ne doit être utilisé qu'une seule et unique fois. Une suppression provoque donc un trou, c'est normal.

Citation:

l'idéal serait lors de la suppression d'une ligne avoir toutes les ligne qui était supérieur à 104 de descendre d'une position.

Il ne faut surtout pas faire cela. Résultat de telles pratiques avec un cas classique :

1. Chargement de la ligne ID 123 pour modification
2. Suppression de la ligne ID 100
3. Modification de l'ID des lignes 101 et plus en ID − 1 => La ligne ID 123 devient ID 122, la ligne ID 124 devient ID 123
4. L'utilisateur qui était en train d'éditer la ligne initialement ID 123 soumet ses modifications => Les modifs sont enregistrées et écrasent les valeurs de la ligne initialement ID 124 :aie:
29/04/2024, 08h27
draidius

Bonjour Séb

Ok donc pour le visuel, il faut que j'adapte le code pour ne pas avoir de trou dans le tableau visible par l'utilisateur...

ça promet quelques de travail ( enfin heure pour moi .. )

Merci pour ta réponse..
donc après pour les insertions les lignes vont se suivre dans la base SQL mais ce sera le n° dans le tableau PHP qui vont changer....
04/05/2024, 21h48
laurentSc

Bonsoir draidius,
as-tu encore une erreur SQL quand tu insères une ligne (sans insérer l'ID vu que c'est auto-incrémenté) ?
04/05/2024, 22h54
Séb.
Citation:

Ok donc pour le visuel, il faut que j'adapte le code pour ne pas avoir de trou dans le tableau visible par l'utilisateur...
ça promet quelques de travail ( enfin heure pour moi .. )

S'il s'agit d'un index de ligne alors tu peux utiliser ROW_NUMBER() :
Code:

1 2 3 4 5 SELECT ALL id, created_at, col1, col2, ROW_NUMBER() OVER (ORDER BY created_at ASC) AS row_index FROM your_table ORDER BY created_at ASC
La colonne row_index vaudra 1 pour la 1re ligne, 2 pour la 2nde, etc. selon l'ordre de tri spécifié (ici selon l'horodatage de création) et en toute indépendance de l'ID.
06/05/2024, 13h50
draidius

Citation:

Envoyé par laurentSc

...

Bonjour laurentSc
Oui, ppiur l'instant le problème est en suspens, j’étais passé à autre chose pour le moment mais je suis preneur de conseil...
Merci

Citation:

Envoyé par Séb.

...

Merci, je vais tester ça :)
06/05/2024, 14h09
laurentSc

Citation:

Envoyé par draidius

Oui, ppiur l'instant le problème est en suspens, j’étais passé à autre chose pour le moment mais je suis preneur de conseil...
Merci

Dans ce cas, donne STP, la structure SQL de ta table (fais un export)
14/05/2024, 08h35
escartefigue

Bonjour draidius

Citation:

Envoyé par draidius

l'idéal serait lors de la suppression d'une ligne avoir toutes les ligne qui était supérieur à 104 de descendre d'une position.

Ce serait non pas l'idéal, mais une très mauvaise chose : ce serait inutile et très couteux, notamment en raison de l'intégrité référentielle.

Cette question revient très fréquemment, c'est pourquoi je lui ai consacré un billet de blog, à lire attentivement ;)

Citation:

Envoyé par laurentSc

Dans ce cas, donne STP, la structure SQL de ta table (fais un export)

Bonjour laurent
Voici la structure:

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
USE [Base_Logiciel_Siege]
GO
/****** Object:  Table [dbo].[Attribution]    Script Date: 15/05/2024 13:37:23 ******/
SET ANSI_NULLS ON
GO
SET QUOTED_IDENTIFIER ON
GO
CREATE TABLE [dbo].[Attribution](
	[ID] [int] IDENTITY(1,1) NOT NULL,
	[nomDepartement] [nvarchar](255) NULL,
	[NomUtilisateur] [nvarchar](255) NULL,
	[NomOrdinateur] [nvarchar](255) NULL,
	[SerialAPPL] [nvarchar](255) NULL,
	[NomLogiciel] [nvarchar](255) NULL,
	[VersionLogiciel] [nvarchar](255) NULL,
	[CleLicence] [nvarchar](255) NULL,
	[EnvSystem] [nvarchar](255) NULL,
	[NumTicket] [nvarchar](255) NULL,
	[DateMAJ] [date] NULL,
	[Verification] [nvarchar](255) NULL,
	[Commentaire] [nvarchar](max) NULL,
PRIMARY KEY CLUSTERED 
(
	[ID] ASC
)WITH (PAD_INDEX = OFF, STATISTICS_NORECOMPUTE = OFF, IGNORE_DUP_KEY = OFF, ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON, OPTIMIZE_FOR_SEQUENTIAL_KEY = OFF) ON [PRIMARY]
) ON [PRIMARY] TEXTIMAGE_ON [PRIMARY]
GO

15/05/2024, 16h20
laurentSc

Citation:

Il ne faut surtout pas faire cela

Citation:

Ce serait non pas l'idéal, mais une très mauvaise chose

Vu les remarques qui t'ont été faites, il ne faut pas chercher à modifier les IDs...
16/05/2024, 14h37
escartefigue
:alerte::alerte::alerte:

Cette table est modélisée avec les pieds :aie:

Citation:

Envoyé par draidius

CREATE TABLE [dbo].[Attribution](
[ID] [int] IDENTITY(1,1) NOT NULL,
[nomDepartement] [nvarchar](255) NULL,
[NomUtilisateur] [nvarchar](255) NULL,
[NomOrdinateur] [nvarchar](255) NULL,
[SerialAPPL] [nvarchar](255) NULL,
[NomLogiciel] [nvarchar](255) NULL,
[VersionLogiciel] [nvarchar](255) NULL,
[CleLicence] [nvarchar](255) NULL,
[EnvSystem] [nvarchar](255) NULL,
[NumTicket] [nvarchar](255) NULL,
[DateMAJ] [date] NULL,
[Verification] [nvarchar](255) NULL,
[Commentaire] [nvarchar](max) NULL,
PRIMARY KEY CLUSTERED
(
[ID] ASC
)WITH (PAD_INDEX = OFF, STATISTICS_NORECOMPUTE = OFF, IGNORE_DUP_KEY = OFF, ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON, OPTIMIZE_FOR_SEQUENTIAL_KEY = OFF) ON [PRIMARY]
) ON [PRIMARY] TEXTIMAGE_ON [PRIMARY]
GO[/CODE]
- Toutes les colonnes sont "nullables", alors que les colonnes "nullables" devraient être l'exception, en l'état, vous pouvez enregistrer une ligne avec seulement un identifiant et rien d'autre :roll:
- Quasiment toutes les colonnes sont de type nvarchar(255), autrement dit, dimensionnées au pif sans tenir compte du réel besoin
- Pour un même identifiant, on trouve un nom d'utilisateur, un nom d'équipement, un nom de département, bref, tout un tas d'attributs qui devraient être remplacés par des clefs étrangères faisant référence à la table des utilisateur, à la table des équipements, des départements...
  Ce faisant, si un même utilisateur a plusieurs ordinateurs, il faudra créer autant de lignes, avec des risques d'orthographies différentes et donc de confusion, de plus, comme c'est le nom qui est stocké au lieu de son identifiant, si plusieurs utilisateurs s'appellent "dupond", on ne saura jamais duquel il s'agit
Il existe un forum consacré à la modélisation, il se trouve ICI
Je vous recommande chaudement d'y exposer votre besoin, car une base de donnée mal modélisée est la source de données non fiables et non intègres, de requêtes complexes et de performances désastreuses.