[HoorayOS] LZ shows you how to store hoorayos desktop information.

Today, LZ will show you how desktop information is stored in the database in hoorayos.

In the first two versions, hoorayos only has apps. The data record method is simple, that is, the string connection method. Because all applications on the desktop come from the tb_app table, you only need to use the primary key id ", "string up. For example:

2,3,45,5,7,11,21,43

Then, the folder function is introduced. The problem is that the desktop is not simply an app, but also a folder. The two types of application data come from two different tables. How can I record the desktop data to a field, it becomes a headache (records cannot be separated, because the desktop icons can be dragged, that is, all applications are interspersed and sorted together ). Later, LZ thought of a stupid method, that is, to set the starting value of the primary key id of the tb_folder table (that is, the folder table) to a large value, such as 1000000, so that LZ still uses the original method to record, if the value is greater than 1000000, the folder is displayed. If the value is greater than, the app is used. For example:

2,3,45,1000001,5,7,21,43,1000003

However, when you query the database, you cannot directly query the database using this SQL statement.

select * from tb_app where id in(2,3,45,1000001,5,7,21,43) order by field(id, 2,3,45,1000001,5,7,21,43)

LZ must first split the string into two groups of Arrays: app and folder, and then query the corresponding tables separately, finally, the returned records are assembled into an array and returned in the original order.

Although it hurts a lot, LZ still enjoys it.

However, this operation mode still has an extreme drawback, that is, the folder primary key id is currently set to 1000000 as the starting point. If the number of apps exceeds 1000000, the data displayed on the desktop will be completely lost and difficult to repair. If no data is backed up, it will be dead.

Although there is a small chance of this drawback, there is still a problem, that is, it is not easy to expand. If the desktop is not only app or folder, but also needs to add other types, such as uploading images to the desktop, at this time, a tb_image table will be added to Store Users' images. Is it necessary to specify a range id for images like folder?

How can I continue to use this stupid method if I am so smart and perfect like LZ ......

--------------- The following content is not yet reflected in the new version, but also in the development and LZ obscenity ---------------

The last method that LZ came up with was to use only id for Mao, and "where id in ()" cannot be used anyway. It would be better to store the application type ...... As a result, the final format may become like this:

app_2,folder_1,image_234,mp3_3,av_7142

In this way, you can avoid the extreme drawbacks, but you are not afraid of expansion. To add a type, you only need to specify the specifications, such as image indicating the image, corresponding to the tb_image table, and mp3 indicating the music, corresponding to the tb_mp3 table; av indicates ......

As for the front-end

LZ stores the types and IDs respectively, corresponding to the type and realid. This makes it easy to obtain the type and id.

OK. This is the entire idea of LZ. If you have a better solution, leave a message to tell LZ.

　　

If you think the LZ solution is ridiculous, don't laugh because

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

Hahaha

.

.

.

.

.

.

.

.

.

.

.

.

End