Início / dba / Perguntas / 66347
Accepted
fehrlich
Asked: 2014-06-02 07:04:18 +0800 CST

Salvar conjunto de dados em outra prática recomendada de tabela

  • 772

Eu quero salvar um conjunto de dados dentro de outra tabela, este conjunto de dados deve ser persistente.

Por exemplo

Table1: FIELDS (A,B,C)
Table2: FIELDS (D, DuplicateTable1)

Posso pensar em 2 possibilidades:

  1. Ter campos A,B,C na Tabela2
  2. Faça uma cópia invisível (por exemplo, adicionando um campo "escondido" na tabela1) e use-o na tabela2 como chave estrangeira.

Eu sinto que ambos não são muito limpos. Como resolveria este problema ?

Editar: Exemplo mais específico:

CREATE TABLE `Bill` (
    `billId` INT(11) NOT NULL AUTO_INCREMENT,
    `to` INT(11) NOT NULL,
    `value` INT(11) NOT NULL,
    PRIMARY KEY (`billId`),
    INDEX `PersonKey` (`to`),
    CONSTRAINT `PersonKey` FOREIGN KEY (`to`) REFERENCES `Person` (`personId`)
)
ENGINE=InnoDB;

CREATE TABLE `Person` (
    `personId` INT(11) NOT NULL AUTO_INCREMENT,
    `name` VARCHAR(50) NULL DEFAULT NULL,
    `address` VARCHAR(50) NULL DEFAULT NULL,
    PRIMARY KEY (`personId`)
)
ENGINE=InnoDB;

Neste exemplo, o problema é que a conta não deve mudar quando a pessoa muda de nome ou endereço. E estou procurando uma boa maneira de consertar isso. Eu poderia adicionar todos os meus campos em Pessoa à minha tabela Bill (por exemplo Bill.person_address). Mas se eu adicionar um novo campo a Pessoa eu também teria que mudar a estrutura da Tabela (o que torna o software menos escalável). Ou a outra maneira que eu poderia pensar, é adicionar um novo campo "bloqueado" a Pessoa como

`locked` TINYINT(1) NULL

E quando salvo uma conta, copio a linha de Pessoa com bloqueado = 1 , então mudaria o aplicativo para que todas as pessoas bloqueadas não apareçam em nenhum outro lugar.

mysql foreign-key

1 respostas

  1. Best Answer

    Se entendi bem, você precisa que a conta ainda tenha os dados da pessoa quando foi criada. E se a pessoa mudou seus dados, como endereço, você precisa que a conta continue com o endereço original onde essa pessoa foi cobrada.

    Em outras palavras, você terá diferentes 'versões' da pessoa. O que eu faria é o seguinte:

    Divida persona tabela em duas tabelas com master-details (or one to many)relação. Na tabela mestre, tenha os campos que não mudam, como ID, Name. Na tabela de detalhes, tenha um campo de chave primária e o ID do mestre e outros campos que podem mudar, como address.

    Person(ID primary key, name , ...)
Person_det(ID PK, Person_id referencing person.id, address, ...)

    A tabela 'Bill' agora teria " person_det.id" como chave estrangeira, em vez de person.id.

    • 1

relate perguntas