[Phpmyadmin-devel] create_tables.sql oddness ?

Marc Delisle delislma at CollegeSherbrooke.qc.ca
Fri Mar 14 05:49:09 CET 2003


Robin H. Johnson a écrit:
> Hi List,
> 
> I was just updated scripts/create_tables.sql so that it could be used
> easier in general as well as used on the automatic demo site in a
> fashion (mainly I it drops the tables before adding them, to avoid
> errors and get the latest versions possible).
> 
> Looking thru it, I noticed they are very uneven in how they handle
> integers:
> PMA_bookmark.id - INT(11) AUTO_INCREMENT
> PMA_table_coords.pdf_page_number - INT 
> PMA_pdf_pages.page_nr - INT(10) UNSIGNED AUTO_INCREMENT
> PMA_column_info.id - INT(5) UNSIGNED AUTO_INCREMENT
> PMA_history.id - BIGINT UNSIGNED AUTO_INCREMENT
> 
> All of the fields should be unsigned first of all, signed values don't
> make sense for them.
> 
> BIGINT is defeintly overkill for the data, it should get changed to INT
> at least.  We aren't going to have more than 2^32-1 history items AFAIK
> ;-).
> 
> For my biggest MySQL box, I had a total of 22 databases, 180 tables and
> 897 fields. This comes to 127mb of data I have.  So that's a a INT(3) I
> could use on PMA_column_info.id already. However, for larger installs, I
> don't know if INT(5) would be enough. 
> 
> AFAIK there are no performance boosts/losses for using smaller/larger
> INT(n) sizes, the only thing that happens is that you need to sort them
> out if you get bigger numbers than that. Could we just set all of them
> to INT(11) as the maximum ? (that's the largest value that makes any
> difference [-2147483648] as well as the default for 'INT').

+1

Thanks,

Marc





More information about the Developers mailing list