联系人 数据库 contacts , data , raw_contacts表相关
联系人data表

类
android.provider.ContactsContract.Data

Constants for the data table, which contains data points tied to a raw contact. For example, a phone number or email address.


Data kinds

Data is a generic table that can hold all kinds of data. Sync adapters and applications can introduce their own data kinds. The kind of data stored in a particular row is determined by the mime type in the row. Fields from DATA1 through DATA15 are generic columns whose specific use is determined by the kind of data stored in the row. For example, if the data kind is Phone.CONTENT_ITEM_TYPE, then DATA1 stores the phone number, but if the data kind is Email.CONTENT_ITEM_TYPE, then DATA1 stores the email address.

ContactsContract defines a small number of common data kinds, e.g. ContactsContract.CommonDataKinds.Phone, ContactsContract.CommonDataKinds.Email etc. As a convenience, these classes define data kind specific aliases for DATA1 etc. For example, Phone.NUMBER is the same as Data.DATA1.

DATA1 is an indexed column and should be used for the data element that is expected to be most frequently used in query selections. For example, in the case of a row representing email addresses DATA1 should probably be used for the email address itself, while DATA2 etc can be used for auxiliary information like type of email address.

By convention, DATA15 is used for storing BLOBs (binary data).

Typically you should refrain from introducing new kinds of data for 3rd party account types. For example, if you add a data row for "favorite song" to a raw contact owned by a Google account, it will not get synced to the server, because the Google sync adapter does not know how to handle this data kind. Thus new data kinds are typically introduced along with new account types, i.e. new sync adapters.

查询操作

／／ 1 Finding all Data of a given type for a given contact
 Cursor c = getContentResolver().query(Data.CONTENT_URI,
          new String[] {Data._ID, Phone.NUMBER, Phone.TYPE, Phone.LABEL},
          Data.CONTACT_ID + "=?" + " AND "
                  + Data.MIMETYPE + "='" + Phone.CONTENT_ITEM_TYPE + "'",
          new String[] {String.valueOf(contactId)}, null);

／／ 2 Finding all Data of a given type for a given raw contact

Cursor c = getContentResolver().query(Data.CONTENT_URI,
          new String[] {Data._ID, Phone.NUMBER, Phone.TYPE, Phone.LABEL},
          Data.RAW_CONTACT_ID + "=?" + " AND "
                  + Data.MIMETYPE + "='" + Phone.CONTENT_ITEM_TYPE + "'",
          new String[] {String.valueOf(rawContactId)}, null);
 

data表存储了大部分的联系人实际信息，他的每一个列的名字之所以这么难看（叫做data1~data15),是因为data表想要存储各种各样的联系人信息，同时不想让每个联系人的数据库列数太长。比如联系人信息里面，光名字就可以分为family name,mid name,nick name；光电话号码可以分为手机，家里，办公室，传真云云；光邮件可以分成这般这般这般那般，相当的纷繁复杂。如果每个信息都作为一个列出现在数据库，那就是硕大一个稀疏矩阵了。
所以data表这样的设计，更实用，也易于扩展；缺点是难看。
不过虽然难看，却不难查询，因为数据库查询的时候，根据data表的mimetype_id来检索需要的内容。
2.1里面，data表的mimetype支持这么十来种，这些不一定能在dump出来的数据库看到，因为一般用不到。。

    *  StructuredName.CONTENT_ITEM_TYPE   //    "vnd.android.cursor.item/name" 

    * Phone.CONTENT_ITEM_TYPE    // "vnd.android.cursor.item/phone_v2"

    * Email.CONTENT_ITEM_TYPE   // "vnd.android.cursor.item/email_v2"
    * Photo.CONTENT_ITEM_TYPE  //    "vnd.android.cursor.item/photo" 
    * Organization.CONTENT_ITEM_TYPE   // .....
    * Im.CONTENT_ITEM_TYPE
    * Nickname.CONTENT_ITEM_TYPE    //  "vnd.android.cursor.item/nickname" 
    * Note.CONTENT_ITEM_TYPE
    * StructuredPostal.CONTENT_ITEM_TYPE
    * GroupMembership.CONTENT_ITEM_TYPE
    * Website.CONTENT_ITEM_TYPE
    * Event.CONTENT_ITEM_TYPE
    * Relation.CONTENT_ITEM_TYPE

对于这些不同类型的查询，有些可以用
ContactsContract.CommonDataKinds.＊来完成，
比如Email

Uri uri = Uri.withAppendedPath(Em