Como você gosta suas chaves primárias? [fechadas]

https://stackoverflow.com/questions/404040

03-07-2019
|

Pergunta

Em uma discussão bastante animada no meu time I foi feito a pensar que a maioria das pessoas como como chaves primárias. Tivemos os seguintes grupos -

Int / BigInt que autoincrement são bons o suficiente chaves primárias.
Deve haver pelo menos 3 colunas que compõem a chave primária.
Id, GUID e identificadores de linha legível humanos todos devem ser tratados de forma diferente.

O que é a melhor abordagem para PKs? Seria fantástico se você pudesse justificar a sua opinião. Existe uma abordagem melhor do que o anterior?

EDIT: Qualquer um tem uma simples amostra / algoritmo para gerar identificadores legíveis para linhas que escalas bem

Solução

Se você está indo fazer qualquer sincronização entre bancos de dados com aplicativos conectados ocasionalmente, então você deve estar usando GUIDs para suas chaves primárias. É uma espécie de dor para a depuração, de modo que para além de que caso eu tendem a vara para ints que autoincrement.

ints AUTOINCREMENT deve ser seu padrão, e não usá-los deve ser justificada.

Outras dicas

Eu não vejo uma resposta que aponta (que eu considero como) o ponto realmente fundamentais - a saber, que a chave primária é o que garante que você não vai ter duas entradas na tabela para o mesmo no mundo real entidade (como modelado no banco de dados). Esta observação ajuda a estabelecer o que são boas e quais são más escolhas para chave primária.

Por exemplo, em uma tabela de (EUA) nomes de estado e códigos, o nome ou o código poderia ser a chave primária - constituem duas chaves candidatas diferentes, e um deles (normalmente o mais curto - o código) é escolhida como a chave primária. Na teoria da dependência funcional (e junte-se dependências - 1NF através 5NF - é as chaves candidatas que são cruciais em vez de uma chave primária

Para um contra-exemplo, nomes humanos geralmente fazem uma má escolha para a chave primária. Há muitas pessoas que vão pelo nome de "John Smith" ou alguns outros nomes semelhantes; mesmo tendo nomes do meio em conta (lembre-se: nem todo mundo tem um - por exemplo, eu não), não há muita margem para a duplicação. Consequentemente, as pessoas não usam nomes como chaves primárias. Eles inventam chaves artificiais, como o Número de Segurança Social (SSN) ou o Número de Empregado e usá-los para designar o indivíduo.

Uma chave primária ideal é curto, original, memorável, e natural. Destas características, singularidade é obrigatória; o resto tem de flexionar dadas as limitações de dados do mundo real.

Quando se trata de determinar a chave primária de uma determinada tabela, portanto, você tem que olhar para o que que a tabela representa. O conjunto ou conjuntos de valores da coluna na tabela identifica exclusivamente cada linha na tabela? Essas são as chaves candidatas. Agora, se cada chave candidata é composto por 4 ou 5 colunas, então você pode decidir que esses são muito desajeitado para fazer uma boa chave primária (principalmente em razão da falta). Nestas circunstâncias, você pode introduzir uma chave substituta - um número gerado artificialmente. Muitas vezes (mas nem sempre) um inteiro de 32-bit simples é suficiente para a chave substituta. Você, então, designar essa chave substituta como a chave primária.

No entanto, você deve ainda garantir que as outras chaves candidatos (para a chave substituta é uma chave candidata também, bem como a chave primária escolhido) são mantidos como identificador único - normalmente pela colocação uma restrição exclusiva sobre os conjuntos de colunas.

Às vezes, as pessoas acham difícil identificar o que faz uma linha única, mas deve haver algo para fazer isso, porque simplesmente repetindo um pedaço de informação não torná-lo mais verdadeiro. E se você não for cuidadoso e fazer entrar dois (ou mais) linhas supostamente para armazenar a mesma informação, e então você precisa atualizar as informações, existe o perigo (especialmente se você usar cursores) que irá atualizar apenas uma linha em vez de cada linha, de modo que as linhas estão fora de sincronia e ninguém sabe qual linha contém as informações corretas.

Esta é uma bonita vista de linha dura, em alguns aspectos.

Eu não tenho nenhum problema em particular com o uso de um GUID quando eles são necessários, mas eles tendem a ser grande (como em 16-64 bytes), e eles são usados ??com muita freqüência. Muitas vezes um perfeitamente bom valor de 4 bytes seria suficiente. Usando um GUID onde um valor de 4 bytes seria suficiente espaço em disco resíduos, e retarda o acesso mesmo indexado aos dados uma vez que há menos valores por página índice, de modo que o índice será mais profunda e mais páginas tem que ser lido para chegar ao informações.

Esta é apenas uma questão religiosa, porque as pessoas procuram uma resposta certa universal. O fato de que tanto sua equipe e isso para espectáculos de rosca tanto desacordo deve ser um indício de que há boas razões para usar todas as soluções que você descreve, em diferentes circunstâncias.

As chaves substitutas são úteis quando nenhum outro atributo ou conjunto de atributos na tabela é adequado para identificar linhas de forma exclusiva.
chaves naturais são preferidos, quando possível, para fazer a tabela mais legível. chaves naturais também permitem que a chave estrangeira em uma tabela dependente para conter um valor real em vez de um ID de substituto. Por exemplo. quando você precisa armazenar state (CA, TX, NY) assim como você pode usar uma chave natural char(2) em vez de um int.
Use compostos chaves primárias se for caso disso. Não adicione uma chave "id" substituto desnecessariamente quando existe um perfeitamente boa chave composto (isto é especialmente verdadeiro em muitos-para-muitos tabelas). Um mandato para uma chave de três colunas em cada tabela é um disparate absoluto.
GUIDs são uma solução quando você precisa para preservar a exclusividade sobre vários sites. Eles também são úteis se você precisar de valores na chave primária para ser único, mas não ordenou ou consecutiva.
INT vs. BIGINT: não é comum que uma tabela requer uma gama de 64 bits para chaves primárias, mas com a crescente disponibilidade de hardware de 64 bits que não deve ser um fardo, e dá mais garantia de que você não vai transbordar. INT é naturalmente menor, por isso, se o espaço é um prémio que pode dar uma ligeira vantagem.

Gosto o programador de banco de dados do blog como uma fonte para este tipo de informação.

3 colunas para uma chave primária? Eu diria que as colunas devem ter restrições exclusivas apropriadas, conforme as regras do negócio exigir, mas eu ainda teria uma chave substituta separado. chaves compostas lógica de negócios médio entra na chave. Se as mudanças de lógica, todo o seu esquema está ferrado.

eu como o meu único.

Eu sempre ir com a chave substituta. Uma chave substituta (normalmente uma coluna de identidade, autoincrement, ou GUID) é aquela em que a chave não está presente nos próprios dados. Uma chave natural, por outro lado, é aquele que, por si só, identifica exclusivamente a linha. Tão perto quanto eu posso dizer na vida, quase não existem chaves naturais reais. coisas nem gosta SSN nos Estados Unidos é uma chave natural. chaves primárias compostas são um desastre esperando para acontecer. Você não pode editar qualquer desses dados (que é o grande inconveniente de qualquer tecla natural, composta ou não), mas pior é que, com uma chave composta, agora você tem a perpetuar que os dados-chave em cada tabela relacionada. Que desperdício gigante.

Agora, para a seleção da chave substituta, eu ficar com colunas de identidade (eu trabalho principalmente em MS SQL Server). do GUID são muito grandes e Microsoft recomenda contra usá-los como um PK. Se você tiver vários servidores, tudo que você precisa fazer é tornar o incremento de 10 ou 20 ou o que você acha que o número máximo de servidores que você realmente precisa para sincronização / expandir-se para, e apenas inc a semente para cada tabela em cada servidor subseqüente e você nunca terá uma colisão de dados.

Claro que, por causa do incremento, que faz a coluna de identidade um BigInt (de outra forma conhecido como um longo [64 bits]).

Fazendo um pouco de matemática, mesmo se você fizer o incremento 100, você ainda pode ter 92,233,720,368,547,758 (> 92 quatrilhões) linhas em sua tabela.

Eu acho que o uso da palavra "Primary", na frase "Primary" Key é em um sentido real, enganosa.

Primeiro, use a definição de que uma "chave" é um atributo ou conjunto de atributos que deve ser exclusivo dentro da tabela,

Em seguida, com uma chave serve a vários propósitos, muitas vezes mutuamente inconsistentes.

Para usar como junta-se condições para um ou vários registros em tabelas filho que têm uma relação a esta tabela pai. (Explicitamente ou implicitamente definir uma chave estrangeira nas tabelas filho)
(relacionados) Garantindo que os registros filho deve ter um registro pai na guia pai; e (A tabela filho FK deve existir como chave na tabela pai)
Para aumentar perforamce de consultas que necessidade de localizar rapidamente um registro específico / linha na tabela.
Para garantir a consistência dos dados, impedindo que as linhas duplicadas que representam a mesma entidade lógica de ser inserido itno a mesa. (Isto é chamado frequentemente uma chave "natural", e deve consistir de mesa) atributos da entidade (que são relativamente invariantes.)

Claramente, qualquer não-meaningfull, chave não-naturais (como um GUID ou um inteiro auto-gerado é totalmente incapaz de satisfazer # 4.

Mas, muitas vezes, com muitos (a maioria) mesas, uma chave totalmente natural que pode fornecer nº 4, muitas vezes consistem em vários atributos e ser excessivamente grande ou tão ampla que usá-lo para fins de # 1, # 2 ou # 3 fará com que consequencecs desempenho inaceitáveis.

A resposta é simples. Use ambos. Use uma chave integrante auto-Generating simples para toda junta e FKS em outras tabelas filho, mas garantir que cada tabela que exige consistência dos dados (muito poucas mesas não) ter uma chave única naturais alternativo que irá impedir inserções de linhas de dados inconsistentes. .. Além disso, se você sempre tem ambos, então todas as objeções contra o uso de uma chave natural (que se muda? Eu tenho que mudar todo lugar é referenciada como uma FK) discutível se tornar, como você não estiver usando-o para isso. .. Você está apenas usando-o na mesma mesa onde é um PK, para evitar dados duplciate inconsistente ...

Como a GUIDs, ter muito cuidado com eles, como a utilização de guids em um índice pode mangueira índice de fragmentação. Os algoritmos mais comuns utilizados para criar os coloca a parte "aleatória" do guid nas posições bit mais significativo ... Isto aumenta a exigência de desfragmentação índice regular / Reindexação como novas linhas são adicionadas.

Um pouco off-topic, mas eu me sinto compelido a carrilhão com ...

Se a sua chave primária é um GUID, não torná-lo um índice de cluster . Desde Guids são não sequencial, os dados serão no disco durante quase todos os inserção rearranjada. (Yuck.) Se usar GUIDs como chaves primárias, eles devem ser índices não clusterizados.

Uma coisa que você nunca deve fazer é usar uma chave inteligente. Isso é uma chave onde as informações sobre o registro é codificado na própria chave, e que acabará por mordê-lo.

Eu trabalhei um lugar, onde a chave primária foi a identificação de conta, que foi uma combinação de letras e números. Não me lembro de nada específico, mas, por exemplo, as contas que eram de um determinado tipo, seria na faixa de 600, e de outro tipo, começou com 400. Isso foi ótimo, até que o cliente decidiu pedir tanto tipos de trabalho. Ou alterado o tipo de trabalho que eles fizeram.

Outro lugar, usou a localização na árvore como chave primária para registros. Assim, não haveria registros como o seguinte.

Cat1.subcatA.record1
Cat1.subcatA.record2
Cat1.subcatB.record1
Cat2.subcatA.record1

É claro que a primeira coisa que os clientes queriam era uma maneira de mover os itens na árvore ao redor. todo o conjunto de software morreu antes que isso acontecesse.

Por favor, por favor, por favor, se você está escrevendo código que eu tiver que manter, por favor, não use uma chave inteligente!

Eu sou um fã da auto-incremento como chave primária. Eu sei no fundo do meu coração que este é um cop-out, mas faz com que seja tão fácil de dados de ordenação por quando ele foi adicionado (ORDER BY ID DESC, instância f'r).

3 colunas soa terrivelmente dura para analisar humanamente.

E esse é o trade-off -. Quanto da capacidade relacional que você precisa, contra tornando esta tabela AQUI compreensível para um ser humano interrogando-lo (versus o procedimento armazenado ou interface de programação)

auto-incremento é para nós seres humanos. : - (

Geralmente, isso depende.

Pessoalmente, eu como ints incremento automático.

Mas, uma coisa que eu posso dizer é que nunca os dados de confiança de outras fontes como a sua chave. Eu juro, cada vez que eu fiz isso ele volta para me morder. Bem, nunca mais!

Deve haver pelo menos 3 colunas que compõem a chave primária.

Eu não entendo isso.

Você está falando de uma "chave natural", por exemplo, "Nome e data de nascimento"? A chave natural pode ser ideal se existir, mas a maioria dos candidatos para uma chave natural são ou não exclusivo (várias pessoas com o mesmo nome) ou não constantes (alguém pode mudar o seu nome).

Int / BigInt que autoincrement são bons o suficiente chaves primárias.

Eu prefiro Guid. Um problema potencial com autoincrement é que o valor (por exemplo, "id ordem") é atribuído pela instância de banco de dados (por exemplo, pelo "banco de dados de vendas") ... que não inteiramente trabalho (em vez de começar a chaves compostas necessidade) se você precisar de dados de mesclagem criados por mais de uma instância de banco de dados (por exemplo, a partir de vários escritórios de vendas cada um com seu próprio banco de dados).

O RE GUID

Watch se este vai ser um acesso rápido realmente realmente realmente realmente banco de dados grande, lotes de carga, e.

No meu último emprego, onde tivemos bancos de dados de 100 a 500 milhões de discos, os nossos rapazes de banco de dados fortemente argumentado contra GUIDs, e para um número decimal de tamanho adequado. Eles sentiram que (sob Oracle) a diferença de tamanho no armazenamento interno para uma cadeia Guid - VS um valor decimal faria uma diferença muito perceptível em pesquisas. (Teclas maiores = árvores mais profundas para atravessar)

A natureza aleatória de GUIDs também reduz o fator de preenchimento para páginas de índice significativamente -. Isso aumenta drasticamente rasgando e disco I / O

Auto incrementar colunas. Eu sou capaz de fazer o meu trabalho de código perfeitamente com o SQL Server ou Oracle, um usando a identidade das outras seqüências usando através do meu DAL, e eu não poderia estar mais feliz. Concordo, GUIDs às vezes são necessárias se você estiver fazendo replicação ou envio de dados afastado para recebê-lo mais tarde afer processamento.

Eu sempre usei uma chave substituta - um inteiro autoincrementável chamada 'id'. Eu posso ver uma abundância de razões para fazer isso, mesmo quando outra opção é óbvia:

Consistência
independente de Dados (único, não destruída por alterações para o formato)
legível

... e não há razão sensata para não:

A ambiguidade na junta? - Aliasing tabelas é uma prática melhor, IMHO
tabelas Optimum? - Remoção de um byte por entrada é otimização prematura, IMHO
decisão Per-mesa? - Não é mais consistente
problemas Escalação? - Eh? Por quê?
estrutura de dados hierárquica? - que é desnormalizar, um todo outro assunto da religião. Basta dizer que eu sou um fã em algumas circunstâncias em teoria, mas nunca na prática:)

razões sensatas contra que eu não tenha pensado ou se deparar ainda são sempre bem-vindas ...

Este é um clássico "depende". Não há uma resposta certa para cada projeto. Eu gosto de coisas diferentes para diferentes situações. Depende se eu estou usando um ORM eo que ele suporta. Depende da arquitectura geral (distribuído ou não, etc). Basta escolher um que você acha que vai trabalhar e passar para discutir sobre tabulações e espaços.

I tendem a usar a opção # 1 ou # 3, dependendo do tamanho, o número de pessoas que ligam, e se é uma situação de vários servidores de banco de dados ou não.

Opção # 2 não faz muito sentido para mim. Se qualquer um dos três não é suficiente para identificar um registro único, então é possível (sem passar por maquinações extras) dois têm dois registros mostram-se com os mesmos valores em todas as três colunas. Se você deseja impor exclusividade em qualquer combinação dos três, em seguida, basta adicionar um índice para eles.

Eu só usar um int auto-incremento ou um GUID. 99% do tempo eu uso auto-incremento int. É apenas o que me ensinaram a usar quando eu aprendi primeiramente sobre bancos de dados e nunca ter executado em uma razão para não usá-los (embora eu saiba de razões pelas quais um GUID seria melhor).

Eu como ints auto incremento porque ajuda com a legibilidade. Por exemplo, eu posso dizer "vejam o registro 129383" e é muito fácil para alguém entrar e encontrá-lo. Com um GUID que é quase impossível de fazer.

Passado uma resposta de definição básica, o que constitui um boa chave primária é deixado em grande parte, à religião e sala de descanso argumentos. Se você tem algo que é, e será sempre, mapa de forma única para uma linha individual, então ele vai funcionar bem como uma chave primária. Passado esse ponto, há outras considerações:

É a definição da chave primária não excessivamente complexa? Será que evitar a introdução de uma complexidade desnecessária para o bem de seguir uma "melhor prática"?
Existe uma melhor possível chave primária que exigiria menos sobrecarga para o banco de dados para pega (ou seja INTEIRO vs. VARCHAR, etc)?
Am I absolutamente certo de que a singularidade e invariante definido-ness da minha chave primária não vai mudar?

Este último é provavelmente o que atrai a maioria das pessoas de usar coisas como GUIDs ou colunas inteiras de auto-incremento, porque depender de coisas como endereços, números de telefone, primeiros / últimos nomes, etc, apenas não cortá-la. A única invariante sobre as pessoas que eu posso pensar é CPFs, mas então eu nem tenho 100% de certeza sobre os restantes para sempre único.

Esperemos que esta ajuda a adicionar alguma clareza ...

A forma como me aproximo chaves primárias (e eu sinto é a melhor) é para evitar ter uma abordagem "default". Isto significa em vez de apenas tapa em um auto-incremento inteiro e chamando-o um dia eu olhar para o problema e dizer "há uma coluna ou grupo de colunas que será sempre unqiue e não vai mudar?" Se a resposta for sim, então eu tomar essa abordagem.

Quase sempre inteiros.

Eles têm outras razões boas além de ser menor / mais rápido a processo. O que você prefere escrever? - "404040" ou "3463b5a2-A02B-4fd4-aa0f-1d3c0450026c"

Apenas um pouco relevante, mas uma coisa que eu comecei a fazer recentemente, quando eu tenho pequenas mesas de classificação (essencialmente aqueles que representaria ENUMS em código) é que eu vou fazer a chave primária de um char (3) ou char (4 ). Então eu fazer essas chaves primárias representante do valor de pesquisa.

Por exemplo, eu tenho um sistema de cotação para nossos agentes de vendas internas. Temos "custo Categorias" que cada item Citação linha é atribuído um dos ... Então, eu tenho uma tabela de tipo de pesquisa chamado 'tCostCategories', onde chave primária é 'MTL', 'SVC', 'TRV', 'imposto', 'ODC'. Outras colunas na tabela de pesquisa armazenar mais detalhes, como os significados Inglês normal dos códigos, "Material", "Serviço", "Viagem", "Impostos", "Outros Custos directos", e assim por diante.

Este é muito bom porque ele não usa mais espaço do que um int, e quando você está olhando para os dados de origem, você não tem que ligar a tabela de pesquisa para saber o que o Parreira é o valor. Por exemplo, uma linha citação pode parecer:

1 PartNumber $ 40 MTL
2 OtherPartNumber $ 29,99 SVC
3 PartNumber2 $ 150 TRV

É muito mais fácil que usando um int para representar as categorias e, em seguida, ligando 1, 2, 3 em todas as linhas - você tem os dados ali mesmo na frente de você, eo desempenho não parece afetado em todos (não que eu realmente testado.)

Quanto à questão real vai ... I como uniqueidentifiers rowguid. Eu não estou 100% sobre isso, mas não todas as linhas têm qualquer forma de rowguid internos ?? Se assim for, em seguida, usando o rowguid seria realmente levar menos espaço do que ints (ou qualquer outra coisa para essa matéria.) Tudo o que sei é que, se é bom o suficiente para M $ para usar em GreatPlains então é bom o suficiente para mim. (Devo pato ??)

Oh mais uma razão que eu uso GUIDs - Eu uso uma estrutura de dados hierárquica. Ou seja, eu tenho uma tabela 'Empresa' e uma mesa 'Vendor' para o qual as chaves primárias igualar-se. Mas também tenho uma tabela 'Fabricante', que também 'herda' da Companhia. Os campos que são comuns a Fornecedores e fabricantes não aparecem nas tabelas - eles aparecem na Companhia. Nesta configuração, usando int do é muito mais dolorosa do que Guids. No mínimo, você não pode usar chaves primárias de identidade.

Eu gosto chaves naturais, sempre que posso confiar neles. Eu estou disposto a pagar um preço pequeno preço desempenho, a fim de utilizar as teclas que fazem sentido para os especialistas no assunto.

Para tabelas que descrevem entidades, deve haver uma chave simples e natural que identifica ocorrências individuais da mesma forma as pessoas no assunto fazem. Se o assunto não tem identificadores de confiança para uma das entidades, então eu vou recorrer a uma chave substituta.

Para tabelas que descrevem relacionamentos, eu usar uma chave composta, onde cada componente referências uma entidade que participa do relacionamento, e, portanto, uma linha em uma tabela entidade. Mais uma vez, o impacto no desempenho para o uso de uma chave composta geralmente é mínima.

Como os outros têm para fora pontas, o termo "chave primária" é um pouco enganador. No Modelo de Dados Relacional, o termo que é usado é "chaves candidatos". Pode haver várias chaves candidatas para uma única tabela. Logicamente, cada um é apenas tão bom quanto outro. Escolhendo um deles como "primário" e fazendo todas as referências via essa chave é simplesmente uma escolha o designer pode fazer.

Guids.period.

No caso em que você precisa de escala para fora ou você precisa atribuir a chave primária por meios alternativos que será seu amigo. Você pode adicionar índices para tudo o resto.

atualização para esclarecer a minha afirmação.

Eu trabalhei em um monte de diferentes tipos de sites. De pequenas ofertas de servidor único para grandes apoiadas com vários servidores de banco de dados e web. Há certamente foram aplicativos que teria sido muito bem com auto incremento ints como chaves primárias. No entanto, aqueles que não se encaixam no modelo de como eu faço as coisas.

Ao usar um GUID pode gerar o ID em qualquer lugar. Pode ser gerado por um servidor remoto, o aplicativo web, dentro do próprio banco de dados ou até mesmo dentro de vários bancos de dados em uma situação de vários mestres.

Por outro lado, um auto incrementado INT só pode ser gerado com segurança dentro do banco de dados principal. Novamente, isto pode ficar bem se você tiver um aplicativo que será intimamente ligado a esse servidor DB um apoio e dimensionamento não é algo que você está preocupado com.

Claro, o uso de GUIDs significa que você tem que ter processos noturno reindexação. No entanto, se você estiver usando qualquer coisa que não seja uma auto incrementado INT você deve fazer isso de qualquer maneira. Heck, mesmo com um INT como o primário é provável que você tem outros índices que precisam ser regeneradas para lidar com a fragmentação. Portanto, usando GUIDs não adiciona exatamente um outro problema, porque essas tarefas precisam ser executadas independentemente.

Se você der uma olhada nas aplicações maiores lá fora, você vai notar algo importante: que todo o uso Base64 codificado GUIDs como as chaves. A razão para isso é simples, o uso de GUIDs permite que você escala a facilmente Considerando que não pode haver um monte de aros para saltar através de ao tentar escalar INTs.

Nosso aplicativo mais recente passa por um período de inserções pesados ??que dura cerca de um mês. Depois que 90 +% das consultas são todos seleciona para relatar. Para aumentar a capacidade de I pode trazer servidores DB adicionais durante este período grande de inserção; e mais tarde facilmente mesclar aqueles em um único DB para relatar. A tentativa de fazer isso com INTs seria um pesadelo absoluto.

Muito francamente, a qualquer momento você agrupar uma replicação de banco de dados ou configurar o servidor de DB vai exigir que você tem GUIDs na mesa de qualquer maneira. Então, se você acha que seu sistema pode precisar de crescer, em seguida, escolher o que é bom.

Este é um assunto complexo se você percebeu ou não. Pode cair sob a seção sobre este StackOverflow FAQ.

Que tipo de perguntas que eu não deveria perguntar aqui?

Evite fazer perguntas que são subjetivas, argumentativo, ou requerem uma discussão alargada. Este é um lugar para questões que podem ser respondidas!

Este tem sido debatida durante anos e continuará a ser debatido durante anos. Os únicos toques de consenso que tenho visto é que as respostas são um pouco previsível, dependendo se você está pedindo um cara OO (GUIDs são a única maneira de ir!), Um modelador de dados (chaves naturais são a única maneira de ir!), ou um DBA orientada desempenho (INTs são a única maneira de ir!).

Licenciado em: CC-BY-SA com atribuição

Não afiliado a StackOverflow