On Sun, Aug 25, 2013 at 6:13 AM, Erik Romijn <[email protected]> wrote:

> I understand your comparison, but the situation is a little different
> here. The integer fields you refer to actually have different storage size
> requirements in many database backends. But for GenericIPAddressField in
> PostgreSQL and SQLite, the column types are the same - INET and TEXT.
>

On MySQL, the type is not char(15) vs char(39), but varchar(15) vs
> varchar(39).
>

The code on master doesn't agree with your statement about mysql and sqlite.

sqlite -
https://github.com/django/django/blob/master/django/db/backends/sqlite3/creation.py#L26

mysql -
https://github.com/django/django/blob/master/django/db/backends/mysql/creation.py#L23



> The storage size required for a varchar is the same for any length from 1
> to 255: one byte to store the content length, and then the bytes of the
> content. So storage size or performance is not affected. On Oracle, it's
> VARCHAR2(15) vs VARCHAR2(39) - I assume they store it similar to MySQL.
>

I don't think that is true for all databases, nor should Django make that
type of assumption. Unless I've misunderstood how MSSQL works, which is
possible, it only adds a few bytes of overhead to the actual data.


> In other words, if you replace an IPAddressField with a
> GenericIPAddressField and store the same data, storage size or database
> performance is not affected, even though the column type may need to be
> changed.
>

This is probably true for some databases, but not guaranteed to be true for
all.

Regards,
Michael Manfre

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to [email protected].
To post to this group, send email to [email protected].
Visit this group at http://groups.google.com/group/django-developers.
For more options, visit https://groups.google.com/groups/opt_out.

Reply via email to