Shulou(Shulou.com)06/01 Report--

problem

Queries in data manipulation are extremely important and frequently used. The concept of views exists in MySQL databases much like queries in Microsoft Access small relational databases. The existence of views greatly reduces the number of data tables created, and there are more advanced techniques to use. This article describes a minor problem to watch out for when reverse-generating ontologies using views in MySQL databases on BeX5, a Start-up technology-based platform.

MySQL database tables correspond to the concept of "physical tables" in BeX5 platform development, but in order to enhance the flexibility of the data layer in software development (the entity structure of the software requirements phase is not determined by one percent; sometimes it needs to be continuously adjusted), the platform introduces the concept of ontology.

In actual development, it is generally necessary to create ontology first, and then generate physical tables from ontology. However, in some cases, when a physical table already exists, it is also necessary to reversely generate an ontology from the physical table.

The importance of views (the ACCESS equivalent of choice queries) was mentioned above; however, to use view technology in BeX5 platform development, you have to deal with ontologies. This requires reverse generation of ontology from views.

First, creating views in MySQL is relatively simple, as follows:

CREATE VIEW v AS mv_homepage_person_viewSELECT a.fID,a.fLegCode,a.fCaseName,a.fBeginDate,a.fWho,b.fPersonName,c.fEndDateFROM MV_LegInfo a,MV_Person2 b,MV_Penalty2 cwhere a.fLegCode=b.fLegCode and b.fLegCode=c.fLegCode

Once the above view is saved, it generates a physical table in MySQL (consistent with Access's generated table query).

Second, on the platform side, the ontology required by platform development can be reversely generated from the table created by the view.

In this process, many students who use this feature for the first time often ignore the selection of the field a.fID when creating the above view, which is used as the primary key in the default platform-generated ontology, and its default value is guid(). If this field is not selected, an error will inevitably occur when referencing the corresponding ACTION of this ontology when creating the UI2-end.W file (the prompt roughly indicates that the fID field is missing)!

solutions

After the above analysis, the solution to the above problems is very simple. However, there are two small issues to note:

(1) When creating a view above, you must select the fID field of a certain table (in fact, it may not necessarily be this field, as long as it is a field until the primary key function is theoretically OK-but the guid() function behind it may not be suitable anymore, and it needs to be expressed flexibly according to needs).

(2) After generating the ontology in reverse, be sure to modify the "primary key relationship", similar to the following figure:

Click on the above "primary key relationship" and select the primary key you selected when creating the view in the pop-up dialog box. Of course, using the default fID as the primary key is highly recommended here. This requires that the fID field be provided in the child table of the generated view (this is supported by default on the platform).

The rest of the operation will not be repeated. Although the child table generated by the view is "dead," the create view statement that creates the view can be easily modified, that is, the temporary table can be created at any time according to the development needs; therefore, the application of the view on the database side is frequent. Correspondingly, the operation of reverse generation of ontology from views on the BeX5 platform will also be high frequency.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.