But now you need an updated model of that database so you've to appeal to reverse engineering to get the new model. You've created a situation where the model is quite outdated compared to the database. Now, for some reason, you started to make additions to your database (that one generated from the model) and not worry about updating the original model. Let's then assume that we've exported that model to a PostgreSQL server, so far so good. One may ask the reason this feature exists and the response could be based upon the following: suppose that you have a fully detailed model with relationships organized by custom points and colors, textboxes being used as small documentation, tables graphically separated by the use of tags and a set of generic SQL objects which hold some specific code for your database being created. Examples of these metadata are tags assigned to tables, textboxes used for general documentation, objects positioning information, relationship colors and custom points, generic SQL objects, and some others. We call metadata all the attributes of objects or even whole objects that aren't converted into SQL code, existing only during design time. The objects metadata handling feature, triggered by the icon in the Fix menu at the control toolbar, comes as a workaround for some lacking present in pgModeler.
0 Comments
Leave a Reply. |