Answer the question
In order to leave comments, you need to log in
Answer the question
In order to leave comments, you need to log in
If you need to display a general list of real estate, sort this list, perform a selection on it, then you should not divide the data into several tables. The search speed will drop as many times as you divide the data into tables (conditionally).
Search time in one log(n) table. Search time in 8 tables with fewer entries = 8*log(n/8).
You can also consider creating a single table with many fields. Fields that do not make sense, just fill NULL.
The problem statement is too vague.
It may well turn out that even EAV will be the best in your case.
In general, the general approach is to compile several lists of fields for different types of data.
Then we find common fields, we try to unite as much as possible.
We have a certain “parent class” and a certain set of extensions.
Next, what do we have in each field? Wouldn't it make sense to make a reference book out of this? (eg employees, areas, types of real estate, etc.). Actually the question is not obvious. Sometimes it's easier to make an enum or a text field.
Some fields from different "classes" can be stored in the same database field if this does not contradict the search logic (For example, the name of the supplier or his full name in the case of a legal entity or an individual is usually one field).
When we get a certain frame, we need to soberly look at this horror and answer - do we need all of them?
If there is no search or sorting by the field, then it may be worth combining several of these fields into one “description” field that is filled in according to the template when you enter it, or contains a serialized array.
It is often advisable to put the general part of the data into a common table, and for each "class" to make a separate table with a link to the main one. Type "real estate objects, details of apartments, details of houses, details of plots of land."
Hands. The real estate is so different that you can have an area for a restaurant, or maybe a warehouse, and their characteristics are very different. Somewhere around two days, as a result, they spent on painting the structure of the database. Although if you just have a site, then this may not be necessary, for the first time I had 8 fields, but there are clean houses and plots. The second time I already wrote something like CRM with a bunch of goodies.
In 2000, we were somehow written a corporate database, which is not needed now. I can give you the source, take a look
Didn't find what you were looking for?
Ask your questionAsk a Question
731 491 924 answers to any question