Use of the Index annotation in the Nutz Dao object (@ TableIndexes @ Index)

Nutz is a collection of lightweight and small frameworks. Each part can be used independently. It encapsulates the essence of SSH in a jar package about 1 MB, nutz does not rely on any other third-party libraries. If you do not consider database links and logs, you only need a jar package for creating a perfect Web application.

As a product, even if it is excellent, if there is no good documentation, it is useless. This is also the advantage of Nutz. It is rare to see detailed open-source frameworks like Nutz.

In short, beebot believes that Nutz is a domestic conscience boutique.

However, what is better about Nutz? It is also an open-source framework maintained by individuals, and there will always be various problems.

Today, I encountered some problems in Entity index annotation. What's the problem? I don't know how to use index annotation...

However, what surprised me was that DU Niang and Google did not find any answer, and the official team did not explain it...

Finally, I found some clues in GitHub. Now I will share my usage!

Suppose there are the following entities:

 

1/** 2 * User 3 * @ author xx 4*5 */6 @ Table ("t_user ") 7 public class User {8/** 9 * Primary Key 10 */11 @ Id12 private long id; 13 14 // other attributes ...... 15 16} 17 18/** 19 * user operation record 20 * @ author xx21 * 22 */23 @ Table ("t_user_record ") 24 public class UserRecord {25 26/** 27 * Primary Key 28 */29 @ Id30 private long id; 31/** 32 * User id (foreign key) 33 */34 @ Column ("user_id") 35 private long userId; 36/** 37 * creation time 38 */39 @ Column ("create_date") 40 private Date createDate; 41 42 // other attributes ...... 43 44}View Code

 

These two entities describe the records generated by the user and the user's use of the system. They are obviously correlated.

Although no one-to-many ing is configured for the dish, we should also know that the userId attribute in the UserRecord object is a foreign key and will be used when two tables are associated, and there may be many userids, not limited, so this field must be indexed.

Since we have mentioned indexes, we will introduce that indexes are not randomly added, and adding more seriously affects the write speed. We should all know that some fields may have only a limited number of values, such as gender, adding indexes does not make much sense.

Too much nonsense... Go to the topic...

Now we need to add an index to the userId attribute of the UserRecord object. Write this statement:

 

1/** 2 * user operation record 3 * @ author xx 4*5 */6 @ Table ("t_user_record ") 7 @ TableIndexes ({@ Index (name = "idx_user_record_user_id", fields = {"userId"}, unique = false )}) 8 public class UserRecord {9 10/** 11 * Primary Key 12 */13 @ Id14 private long id; 15/** 16 * User id (foreign key) 17 */18 @ Column ("user_id") 19 private long userId; 20/** 21 * creation time 22 */23 @ Column ("create_date") 24 private Date createDate; 25 26 // other attributes ...... 27 28}View Code

 

You only need to add the @ TableIndexes annotation to the object class, and each @ Index annotation in it can be understood as an Index declaration.

For example, you want to define Multiple indexes:

 

1 @ TableIndexes ({@ Index (name = "idx_user_record_user_id", fields = {"userId"}, unique = false), 2 @ Index (name = "index_name ", fields = {"fieldName1", "fieldName2"}, unique = false )})View Code

 

The specific parameters in the @ Index annotation are described as follows:

 

NameIndex name. Because the index is global, we recommend that you add a table name to the name to avoid conflicts.

FieldsIndexAttributeSet, that is, the attributes on which the index is created. Because an index can be added to not only one field, but also to multiple fields, it is called a joint index. Note: The dishes are always being emphasizedAttributeThe value in fields is the object attribute name, not the field name in the database table.

UniqueWhether it is a unique index. There are roughly three types of indexes: normal index, unique index, and full-text index. A common index is simply an index, while a unique = false is a normal index. A unique index adds a unique constraint on a general index to ensure that this field is not repeated, unique = true is the unique index. Full-text indexes are complex. One table can only be created. It is optimized for super-long string search. It is not supported by Nutz and is generally unavailable. It is not much to say about the dishes!

 

At the end of this article, I would like to talk more about joint indexing.

We often use such SQL statements:

 

1 SELECT * FROM T_TABLE WHERE FIELD1=? AND FIELD2=? AND FIELD3=?

 

If such queries are very frequent and the data volume is large, we have to consider adding indexes to FIELD1, FIELD2, and FIELD3, but it is a waste to add three independent indexes at once, therefore, you can add a joint index on FIELD1, FIELD2, and FIELD3.

In addition, if the probability of a field being queried separately is relatively high when the Union index is added, the field must be placed first. Taking the example just now, if FIELD2 is often queried separately, then join indexes are added in the order of FIELD2, FIELD1, and FIELD3.

This is a simple thing. After talking about so many dishes, the article is over and I wish readers a smooth learning experience!