• Hello Fabrik Community

    Fabrik is now in the hands of the development team that brought you Fabrik for Joomla 4. We have recently transitioned the Fabrik site over to a new server and are busy trying to clean it up. We have upgraded the site to Joomla 4 and are running the latest version of Fabrik 4. We have also upgraded the Xenforo forum software to the latest version. Many of the widgets you might have been used to on the forum are no longer operational, many abandoned by the developers. We hope to bring back some of the important ones as we have time.

    Exciting times to be sure.

    The Fabrik 4.0 Official release is now available. In addition, the Fabrik codebase is now available in a public repository. See the notices about these in the announcements section

    We wish to shout out a very big Thank You to all of you who have made donations. They have really helped. But we can always use more...wink..wink..

    Also a big Thank You to those of you who have been assisting others in the forum. This takes a very big burden off of us as we work on bugs, the website and the future of Fabrik.

Type question for internal id and its dimension

rdiana

Member
Dear Rob and Hugh,
I've a question about the primary key for each table.
When I create a list/table, the field id (internal id) is created but no "advanced" option about its type is present (for example: smallint, int...). I think it would be very useful to avoid not necessary bytes in short tables or, on the contrary, use enough bytes in long tables (a user list, for example).
On the other hand, I've noticed (by using phpmyadmin) in some tables the id field is 6 bits long, in other is 11 bits long. The dimension is dinamically changed?

Cheers,

Roberto
 
The 6 and 11 "size" you are referring to doesn't actually affect the numeric size of the field, it's simply the "display width" which is available to applications, so they can optionally present the data with padding. As per the MySQL documentation:

For example, INT(4) specifies an INT with a display width of four digits. This optional display width may be used by applications to display integer values having a width less than the width specified for the column by left-padding them with spaces. (That is, this width is present in the metadata returned with result sets. Whether it is used or not is up to the application.)

The display width does not constrain the range of values that can be stored in the column. Nor does it prevent values wider than the column display width from being displayed correctly.

So UNSIGNED INT(6) and UNSIGNED INT(11) are no different in that they can both handle integers up to 4,294,967,295. If you need more than 4.2 billion records, then you probably don't need to be using Fabrik. ;)

And if you really, really need to save 2 bytes per row by using a SMALL or TINY int, then you can simply set "Alter existing fields" on your list settings to "No", then go in to phpMyAdmin and change your PK type. But I really can't imagine any situation where saving 2 bytes per row is going to help. Even if you have a million rows, that's only 2MB of space ... which in today's storage terms is negligible.

-- hugh
 
We are in need of some funding.
More details.

Thank you.

Members online

Back
Top