@Steven A. La réponse de Lowe est certainement le plus simple, moins d'impact sur les applications existantes.
Juste pour les grimaces et les fous rires, supposons que vous souhaitiez apporter d'autres modifications au schéma (nouvelles tables, colonnes).
Je regarderais attentivement les tables avant de combiner quoi que ce soit - assurez-vous que les entités/relations représentées par les tables sont cleat et normalisées. Si publisher et designer sont vraiment la même chose, la même entité, alors une nouvelle table combinant les deux pourrait être souhaitable. Créez la nouvelle table avec un nouvel identifiant unique. Il existe plusieurs façons d'associer cet ID aux tables d'origine. Structurer l '«histoire» (d'où il vient et l'ancien id) va exiger quelques colonnes, idéalement dans un tableau séparé (parce qu'ils ne sont pas vraiment «sur» la nouvelle table, non?), Mais ils pourraient être inclus dans la nouvelle définition de la table.
Quelque chose comme
new table
column newId
.
.
.
column oldTableName
column oldId
ou
new table
column newId
.
.
.
join table
column newId
column oldTableName
column oldId
Vous pouvez ensuite créer une ou plusieurs vues qui présente l'ancienne structure de table pour les applications existantes.
create view oldTable id, [...] as
select oldId, newTable.col1, newTable.col2
where oldTableName = 'oldTable
Il existe d'autres méthodes pour fusionner les ID, mais les deux décrites ici sont probablement suffisantes.