[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