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".
– Caffé
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...
– Felipe Sachetti
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 AnoandNotaFiscalEntrada.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.– Caffé
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...
– Felipe Sachetti