bonjour,
je migre un ancien projet 5.5 en 7.5 alternatif (je ne parle pas de voltage,
les intéressés auront compris.) ;)
dans l'ancienne alalyse, je n'avais ni identifiant automatique, ni relation
entre fichiers.
Dans le nouveau projet, en mysql/innodb, je voudrais gérer des foreign keys
avec des contraintes sur delete et update.
D'où la difficulté de récupérer l'existant chez mes clients en 5.5.
Comment procéder ?
Puis-je modifier l'analyse 5.5 en ajoutant les ID auto + les clés
"étrangères" dans les fichiers reliés ?
Est-ce que la validation de tout ça va créer les clés (je pense que oui), et
les clés reliées (là, je suis moins sûr) ?
Bref : que du bonheur :)
toutes les suggestions seront les bienvenues.
merci
--
Jacques TREPP
Albygest
---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.577 / Virus Database: 366 - Release Date: 03/02/2004
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
Roumegou Eric
jacques trepp avait écrit le 04/02/2004 :
bonjour, je migre un ancien projet 5.5 en 7.5 alternatif (je ne parle pas de voltage, les intéressés auront compris.) ;) dans l'ancienne alalyse, je n'avais ni identifiant automatique, ni relation entre fichiers. Dans le nouveau projet, en mysql/innodb, je voudrais gérer des foreign keys avec des contraintes sur delete et update.
des contraintes sur delete, je vois bien (supression en cascade) des contraintes sur update ?Que veux tu faire ? pas modifier l'id quand meme qui doit être une clé de pref numérique (pas de signifiant dans un identifiant primaire.) ou répercuter la modif d'une zone dans une autre table (zones redondantes).
Perso, après avoir travaillé avec les deux méthodes (contraintes sur le modèle de données, contraintes dasn les prog) je préfère gérer les contraintes d'intégrité par prog.
Pour intégrer des données c'est plus souple.
D'où la difficulté de récupérer l'existant chez mes clients en 5.5. Comment procéder ? Puis-je modifier l'analyse 5.5 en ajoutant les ID auto + les clés "étrangères" dans les fichiers reliés ? Est-ce que la validation de tout ça va créer les clés (je pense que oui), et les clés reliées (là, je suis moins sûr) ?
Si je comprends bien, tu vas utiliser SQLManagerX.
Si tu prog en sql natif, tu n'as que faire de l'analyse (c'est qd meme pratique d'en avoir une à jour mais pour le dev).
Si tu modifies tes bases en rajoutant des identifiants, je pense que tu devrais développer des prog de migrations de données; ne serait-ce que pour récupérer des id dans les tables dépendantes.
Bref : que du bonheur :)
toutes les suggestions seront les bienvenues. merci
-- Eric Roumegou http://cerbermail.com/?Wk2D8D62KI (cliquez sur le lien ci-dessus pour me contacter en privé)
jacques trepp avait écrit le 04/02/2004 :
bonjour,
je migre un ancien projet 5.5 en 7.5 alternatif (je ne parle pas de voltage,
les intéressés auront compris.) ;)
dans l'ancienne alalyse, je n'avais ni identifiant automatique, ni relation
entre fichiers.
Dans le nouveau projet, en mysql/innodb, je voudrais gérer des foreign keys
avec des contraintes sur delete et update.
des contraintes sur delete, je vois bien (supression en cascade)
des contraintes sur update ?Que veux tu faire ?
pas modifier l'id quand meme qui doit être une clé de pref numérique
(pas de signifiant dans un identifiant primaire.) ou répercuter la
modif d'une zone dans une autre table (zones redondantes).
Perso, après avoir travaillé avec les deux méthodes (contraintes sur le
modèle de données, contraintes dasn les prog) je préfère gérer les
contraintes d'intégrité par prog.
Pour intégrer des données c'est plus souple.
D'où la difficulté de récupérer l'existant chez mes clients en 5.5.
Comment procéder ?
Puis-je modifier l'analyse 5.5 en ajoutant les ID auto + les clés
"étrangères" dans les fichiers reliés ?
Est-ce que la validation de tout ça va créer les clés (je pense que oui), et
les clés reliées (là, je suis moins sûr) ?
Si je comprends bien, tu vas utiliser SQLManagerX.
Si tu prog en sql natif, tu n'as que faire de l'analyse (c'est qd meme
pratique d'en avoir une à jour mais pour le dev).
Si tu modifies tes bases en rajoutant des identifiants, je pense que tu
devrais développer des prog de migrations de données; ne serait-ce que
pour récupérer des id dans les tables dépendantes.
Bref : que du bonheur :)
toutes les suggestions seront les bienvenues.
merci
--
Eric Roumegou
http://cerbermail.com/?Wk2D8D62KI
(cliquez sur le lien ci-dessus pour me contacter en privé)
bonjour, je migre un ancien projet 5.5 en 7.5 alternatif (je ne parle pas de voltage, les intéressés auront compris.) ;) dans l'ancienne alalyse, je n'avais ni identifiant automatique, ni relation entre fichiers. Dans le nouveau projet, en mysql/innodb, je voudrais gérer des foreign keys avec des contraintes sur delete et update.
des contraintes sur delete, je vois bien (supression en cascade) des contraintes sur update ?Que veux tu faire ? pas modifier l'id quand meme qui doit être une clé de pref numérique (pas de signifiant dans un identifiant primaire.) ou répercuter la modif d'une zone dans une autre table (zones redondantes).
Perso, après avoir travaillé avec les deux méthodes (contraintes sur le modèle de données, contraintes dasn les prog) je préfère gérer les contraintes d'intégrité par prog.
Pour intégrer des données c'est plus souple.
D'où la difficulté de récupérer l'existant chez mes clients en 5.5. Comment procéder ? Puis-je modifier l'analyse 5.5 en ajoutant les ID auto + les clés "étrangères" dans les fichiers reliés ? Est-ce que la validation de tout ça va créer les clés (je pense que oui), et les clés reliées (là, je suis moins sûr) ?
Si je comprends bien, tu vas utiliser SQLManagerX.
Si tu prog en sql natif, tu n'as que faire de l'analyse (c'est qd meme pratique d'en avoir une à jour mais pour le dev).
Si tu modifies tes bases en rajoutant des identifiants, je pense que tu devrais développer des prog de migrations de données; ne serait-ce que pour récupérer des id dans les tables dépendantes.
Bref : que du bonheur :)
toutes les suggestions seront les bienvenues. merci
-- Eric Roumegou http://cerbermail.com/?Wk2D8D62KI (cliquez sur le lien ci-dessus pour me contacter en privé)
jacques trepp
Roumegou Eric wrote:
des contraintes sur delete, je vois bien (supression en cascade) des contraintes sur update ?Que veux tu faire ?
non, c'est surtout pour empêcher les delete tant qu'il reste des contraintes d'intégrité. De toutes façons, je suis bon pour la moulinette qui tue. Pour les tables qui n'ont pas bougé, c'est tout bon. Pour les autres ...
Perso, après avoir travaillé avec les deux méthodes (contraintes sur le modèle de données, contraintes dasn les prog) je préfère gérer les contraintes d'intégrité par prog.
Pour intégrer des données c'est plus souple.
Je vais peut-être faire comme ça, si je ne peux pas faire autrement.
merci
-- Jacques TREPP Albygest
--- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.577 / Virus Database: 366 - Release Date: 03/02/2004
Roumegou Eric wrote:
des contraintes sur delete, je vois bien (supression en cascade)
des contraintes sur update ?Que veux tu faire ?
non, c'est surtout pour empêcher les delete tant qu'il reste des contraintes
d'intégrité.
De toutes façons, je suis bon pour la moulinette qui tue.
Pour les tables qui n'ont pas bougé, c'est tout bon.
Pour les autres ...
Perso, après avoir travaillé avec les deux méthodes (contraintes sur
le modèle de données, contraintes dasn les prog) je préfère gérer les
contraintes d'intégrité par prog.
Pour intégrer des données c'est plus souple.
Je vais peut-être faire comme ça, si je ne peux pas faire autrement.
merci
--
Jacques TREPP
Albygest
---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.577 / Virus Database: 366 - Release Date: 03/02/2004
des contraintes sur delete, je vois bien (supression en cascade) des contraintes sur update ?Que veux tu faire ?
non, c'est surtout pour empêcher les delete tant qu'il reste des contraintes d'intégrité. De toutes façons, je suis bon pour la moulinette qui tue. Pour les tables qui n'ont pas bougé, c'est tout bon. Pour les autres ...
Perso, après avoir travaillé avec les deux méthodes (contraintes sur le modèle de données, contraintes dasn les prog) je préfère gérer les contraintes d'intégrité par prog.
Pour intégrer des données c'est plus souple.
Je vais peut-être faire comme ça, si je ne peux pas faire autrement.
merci
-- Jacques TREPP Albygest
--- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.577 / Virus Database: 366 - Release Date: 03/02/2004
