FrankRuperto's questions

11.70.FC6 Developer Edition no Windows 7 Pro de 64 bits:

1. Baixei através do link IIUG e instalei.
2. Criei uma instância DSS personalizada chamada "servidor" com um dbspace de 128 GB chamado "datadbs".
3. O assistente de instalação criou um usuário do Windows "informix".
4. Eu me conectei à instância "servidor", logando como "informix".
5. Executou um script SQL "CREATE DATABASE voters IN datadbs NLSCASE INSENSITIVE;"
6. Isso falhou (veja a primeira imagem), então tentei criar o banco de dados por meio do menu dbaccess.
7. No dbaccess, as opções do dbspaces não mostravam "datadbs", apenas root, phys, log & sbs dbs', mas quando faço um dir do dbspaces ele mostra "datadbs" com 107GB (veja a segunda imagem).
8. Eu defino os seguintes valores em "onconfig.server" (veja a terceira imagem), mas ainda sem dados!

Em uma casa de penhores, os clientes penhoram, vendem ou compram itens. Um contrato que especifica as informações dos clientes, os itens e os termos e condições é criado sempre que os clientes penhoram, vendem ou compram itens.

São permitidos até 6 itens por contrato. Se houver mais de 6, eles devem ser divididos em contratos separados. A razão para este limite é porque apenas um único contrato pode existir por formulário impresso. O formulário tem 8,5 por 5,5 polegadas (tamanho da metade da página), portanto, apenas 6 descrições de itens cabem em cada formulário. Legalmente, não podemos ter a página 1 de 2 para o mesmo contrato.

Todos os itens pertencentes a um contrato recebem um número de sequência de lote. Esse número de lote também é o número do contrato. O número do lote incrementa, independentemente de ser um contrato de penhor, compra ou venda. Cada tipo de contrato manterá seu próprio número de sequência de recebimento. Visualize um bloco separado para contratos de penhor com um número de recibo no canto superior direito, um bloco separado para compras e um bloco separado para vendas.

Vendas e compras são definitivas!

No entanto, os clientes podem fazer pagamentos de juros sobre seus peões ativos, caso em que o cliente fornece ao caixa uma cópia do recibo original, juntamente com o pagamento de juros. Em seguida, um novo recibo para os mesmos itens penhorados (ou seja, com o mesmo número de lote) é emitido, mostrando uma nova data de vencimento e o recibo original ou anterior é cancelado e arquivado pelo caixa.

Quando os clientes resgatam seus peões, nenhum novo recibo é emitido. O cliente assina o recibo, informando que os itens penhorados foram devolvidos a ele, o recibo é cancelado pelo caixa e arquivado.

À medida que outros clientes penhoram itens ou fazem pagamentos de juros, novos recibos são emitidos e entregues aos clientes.

EDIT: Se a casa de penhores não fornecesse um novo recibo para cada pagamento de juros, apenas atualizasse o contrato original com data de pagamento de juros, valor e nova data de vencimento, não teríamos complicações! No entanto, temos um número de recibo de peão que às vezes aumenta e às vezes não, dependendo do tipo de transação operada em cada peão.

O seguinte é um exemplo de transações de peão durante um período de tempo:

    CUSTOMER   TRANSACTION DATE/TIME   TRANSACTION TYPE     RECEIPT#
    --------   ---------------------   ----------------     --------

    Frank      Oct-28-2012,  9:00 am   New Pawn, Lot#501      P12345
    Mark       Oct-28-2012,  9:05 am   New Pawn, Lot#502      P12346
    Jeff       Oct-28-2012,  9:20 am   New Pawn, Lot#503      P12347

    ...
    (several other new pawns, which increment the lot and receipt numbers, and  
     interest payments which only increment the receipt numbers.)

    Mark       Nov-26-2012, 12:30 pm   Pawn Lot#502, Int Pymt P12945
    Frank      Nov-26-2012, 12:32 pm   Pawn Lot#501, Redeemed P12345 (no change)
    Jonathan   Nov-26-2012, 12:35 pm   New Pawn, Lot#600      P12946
    ...

    Jeff       Jan-30-2013, 12:39 pm   Pawn Lot#503, Forfeit  P12347 (no change)

Como você pode ver, os números dos lotes de peões nunca mudam ao longo da vida ou morte do peão, mas os números dos recibos aumentam à medida que diferentes clientes fazem pagamentos de juros sobre os peões existentes ou penhoram novos itens. Se um cliente não fizer nenhum pagamento de juros ou resgatar os itens penhorados até a data de vencimento, o cliente perderá os itens penhorados (o número do recibo permanece o mesmo) e a casa de penhores colocará esses itens em seu estoque.

BTW, quando a casa de penhores puxa um peão amadurecido, cada item nesse peão recebe o número de recibo mais atual, sufixado com o número do item dentro de cada contrato. Em seguida, eles são transferidos para o inventário da casa de penhores.

Assim, o segundo item no lote de penhora número 503, tendo um número de recibo de P12347, seria transferido para o estoque com um número de estoque atribuído de "P12347-2", onde "P" significa Penhor, "12347" era o recibo atual número e "-2" porque era o segundo item dentro daquele contrato de peão.

Eu pessoalmente não usaria esse esquema de numeração, mas muitas casas de penhores no meu bairro gostam de fazer as coisas dessa maneira porque afirmam que podem dizer quando foi a última vez que um determinado peão teve alguma atividade, com base em seu número de recibo, mais eles pode manter todos os seus peões fisicamente armazenados em ordem cronológica, facilitando a sua retirada.

Então, dadas as regras e exemplos acima, qual é a melhor maneira de projetar as tabelas e relacionamentos para essas regras, usando um banco de dados SQL como Informix ou MS-Access 2010 JetDB?

Seria melhor se houvesse uma tabela de contratos para todos os peões, compras e vendas ou tabelas de contratos separadas para cada um? E a tabela de transações que opera sobre a tabela de contratos?

Informix 11.70.TC4DE:

CREATE TABLE cluster_tbl
    (
fk_id INT,
data CHAR(2048)
    );

LOAD FROM "presorted.ld" INSERT INTO cluster_tbl;

CREATE UNIQUE CLUSTER INDEX cl_idx ON cluster_tbl(fk_id);

{###}

CREATE TABLE noncluster_tbl
    (
fk_id INT,
data CHAR(2048)
    );

LOAD FROM "presorted.ld" INSERT INTO noncluster_tbl;

CREATE UNIQUE INDEX ncl_idx ON noncluster_tbl(fk_id);

{###}

UPDATE STATISTICS;

Entendo que um índice de cluster é essencialmente o mesmo que pré-classificar o arquivo de carregamento, inseri-lo na tabela e criar o índice para a coluna de chave estrangeira.

Criei duas tabelas, cada uma carregada com 2 milhões de linhas de dados idênticos, pré-classificados pela chave estrangeira. No entanto, uma tabela possui um índice de cluster em fk_id, a outra tabela com um índice não clusterizado em fk_id.

Existe alguma diferença na estrutura da árvore ou sobrecarga adicional em manter ou acessar dados de uma tabela com um índice de cluster em comparação com a mesma tabela/dados com um índice sem cluster?