DB clean up

[akrguda]

Part 1:

We checked the DB Model as it is now. We noticed, that there a some parts, that will not work fine with the application we wanted to build. The changes to made are marked yellow on the next diagram (part 1) and (part 2 and 3) later on.

What is the problem? We got redundant datafields that may leads to problems with the category. As you can see in the diagram we got the table category and the key is part of the table topic. The next table topic_value has the relation also to the table categorie. In the worst case, somebody select the categorie "appartement" and enter in the topic_values values from the categorie "car". So, we removed this part because eacht topic_value belongs to a topic and a topic belongs to a categorie. On this way it is always clear wich categorie a "topic_value" belongs to. This are the changes for part 1.

[akrguda]

Part 2:

When we checked the DB Model we found the table field_type_choose in wich we can select subcategories of a row. The values were

'Zimmer' 'Wohnung' 'Haus' 'Parkplatz'

So with this values and the combination with fild_type and category it was possible, to add a car park to a appartement wich is furnished and on the 2 flooer for example. So, this table is a subcategory of category. The model was changed to the following design

The originaltable field_type_choose (l.a. diagram 1) was droped and integrated in the new table category_detail. To find the category of a field_type is the same way as it descripted in part 1 (p.c. comment about part 1).

[akrguda]

In the diagram part 1 you can see, that ther's a table address but not relation to the data model. The relations are done now. Now an address can be added to a topic item. An address can be added to a advertiser. Please notice: an advertiser may not wish to make the address public or a topic-item is mobile / in a stock somewhere and has no direct address. That's the reason, why the relations are made with null-able adress_id in the target table. You may add an address but you do not have to do it as an fix requirement.

[akrguda]

Next steps: we will discus all the changes an prepare the db-scripts that we can use it on the postgres database. When we do it directly on the datamodel now, the prototype application, that works so fare today, will not work anymore. We have to do a planing, whow does the changes on the database and also whow makes the changes in the app for the new parts. When both parts are ready we can plan the date on to the changes at the application and database.

[akrguda]

@fingeririna

Hallo Irina, ich habe die geplanten Aenderungen im Ticket nachgeführt. Wir werden morgen im Daily die Aenderungen im Team besprechen und das weitere Vorgehen planen. Gruss Daniel

[TimmyAeberli]

Hätte man anpassen können/sollen. Zum jetzigen Zeitpunkt muss das nicht mehr aufgerollt werden, da daraus zu viele Anpassungen hervorgehen müssten.