Group tables into a single

Asked

Viewed 347 times

4

We are updating a system developed in Delphi q stored the data in access tables for Postgresql. So far so good, however, I have come across the following situation::

In the old bank we had the following tables to store the drives:

  • notafiscal
  • notafiscalitem
  • request
  • pedidoitem
  • coupon
  • cupomitem
  • noted
  • noteworthy

To standardize thought of grouping everything facilitating updating of fields and grouping everything in a single table (sic):

  • movement
  • bustle

Creating a field that differentiated one throw from the other.

Can this cause slowness? Is it an acceptable technique? What are the pros and cons?

  • Just to standardize? Don’t you have a more tangible reason? I already used this model (the tables were called "document" and "documentItem") and the problem is the huge amount of fields that they ended up reaching (more than 500 columns each). Hence: redundant fields because no one else knew what could be reused, even field for different purposes, null fields because they made no sense for all records, slowness and impossibility to delete records given the amount of FK. But all of this depends on many factors. So I ask if you have other reasons besides "standardization".

  • Besides the standardization, for me it would be easier to update, because, some fields are added in both tables, an example would be invoice and invoice.... thinking about what you said is really going to be necessary... I believe that some documents are possible to group, budgets, requests, conditional, but not all...

  • Sometimes the field has similar purpose and identical name but is not the same field as it belongs to distinct entities. Consider: NotaFiscal.Número e Série e Ano and NotaFiscalEntrada.Número e Série e Ano. The first cannot be repeated while the second has a probability of receiving repeated data. Even if you use a key surrogate (a sequential and meaningless field for the business) as the PK of your table, the fact is that these fields belong to distinct entities so they can be "repeated" in different tables.

  • really, thinking this way and to ensure the distinction of the records, the best way would be a table for each type of document... the price of standardization and the ease of possible updates is less than that of management of giant tables...

1 answer

1

The normalization serves to ensure that the data is distinct and that there is a better maintenance of the data in your case, so the old database is normalized in distinction of the "update" of the database that is in the presented form as a table "does everything" that has a lot of data that cannot be grouped or are "repeated":
inserir a descrição da imagem aqui Normalização de Dados

You can normalize by following the standard of the 5 Normal Forms (Fns) given this example below a rental company for being simpler and presenting fewer tables after being standardized: 1FN

2FN

3FN

4FN

  • It looks like you didn’t make these slides. Can they be played without problems? You could quote the source?

  • @bigown these slides are made available on this site http://www.softblue.com.br/ full sql course.. had a time I had seen and remembered that there was a material that could use to help your problem^^

Browser other questions tagged

You are not signed in. Login or sign up in order to post.