BIND 10 #2766: reconsider the use of varbinary in database tables

[BIND 10 Development]

#2766: reconsider the use of varbinary in database tables
-------------------------------------+-------------------------------------
            Reporter:  cas           |                         Type:
              Status:  new           |  enhancement
           Milestone:  New Tasks     |                     Priority:
            Keywords:                |  medium
           Sensitive:  0             |                    Component:  dhcp4
         Sub-Project:  DHCP          |                 CVSS Scoring:
Estimated Difficulty:  0             |              Defect Severity:  N/A
         Total Hours:  0             |  Feature Depending on Ticket:
                                     |          Add Hours to Ticket:  0
                                     |                    Internal?:  0
-------------------------------------+-------------------------------------
 The dhcp4 component (maybe also the dhcp6 component) makes use of the
 varbinary datatype:

 | hwaddr         | varbinary(20)    | YES  | MUL | NULL              |
 |
 | client_id      | varbinary(128)   | YES  | MUL | NULL              |
 |

 while this might give a performance benefit over text encoded fields, it
 makes working with common "off the shelf" database tools difficult, as the
 value stored is just a binary blob and hard for a user to work with.

 if the performance penalty is not too big, the use of varbinary might be
 reconsidered in favor for a dataype that is easy to handle for users (e.g.
 typing into SQL statements in the mysql command line tool when searching
 for all leases of a certail client-id or hw-address).

 searching for a hw-addr in an SQL database is quite a common task for DHCP
 administrators. A common text encoding (08:00:27:CB:AA:68) would make that
 task much easier.

-- 
Ticket URL: <http://bind10.isc.org/ticket/2766>
BIND 10 Development <http://bind10.isc.org>
BIND 10 Development