• 8.3 (unregistered) in reply to OldCoder

    Ha

  • dude (unregistered) in reply to Zemm
    Zemm:
    Ah, no. CHARs are stored space-padded within the row data but the data for VARCHARs are stored in a separate place. Spaces on the end of CHARs are stripped on retrieval, but not VARCHARs. This is MySQL versions after 5.0.3, but my quick Google suggests this is true for most other DBs too.

    No, VARCHAR are always stored in the row (contributing to the 65535 maximum record length in MySQL, even after 5.0.3) while TEXT fields are stored elsewhere.

    MSSQL also has VARCHAR(max) which appears to allocate 8k in the record and uses that if the text fits, otherwise it stores it elsewhere.

    It's unlikely there are enough records to justify the time it would have taken to set the column width correctly.

  • Mr. AHole DBA (unregistered) in reply to Anon
    Anon:
    Mr. AHole DBA:
    Nothing wrong with denormalization in the days of 64 bit computing

    Why would denormalizing be a bad decision on a 32 bit processor whereas it would be a fine decision on 64 bit?

    64 bit computing really opened up one of the main areas we were having a lot of problem with even in the early 2000s: RAM and reading from disk.

    Having the 4GB limit of RAM removed meant that now DBAs too can get lazy like developers when writing highly efficient code. We used to spend a lot of time optimizing by getting every last megabyte of data we need in memory, and trying to keep all others away with swords and spikes. However, that was impossible, so we had to come up with ways of maximizing spinning disks.

    Now with FusionIO cards, and 64 GB of ram standard on many machines, we don't care about normalization as much as we did. Licensed products also seem to charge per CPU, so removing joins and maximizing CPU time by offloading it to memory is a legitimate tactic.

    It's also helped a lot in parallel computing using products like Hadoop, but that's for the nuances of the map-reduce-sort jobs.

  • Neil (unregistered) in reply to Toadworld
    Toadworld:
    S, V F X.
    F U N E M?
  • Norman Diamond (unregistered) in reply to Neil
    Neil:
    Toadworld:
    S, V F X.
    F U N E M?
    有
  • Anonymous (unregistered) in reply to Mr. AHole DBA

    Whoosh.

  • human (unregistered) in reply to faoileag

    It might be a self-documenting clue as to the strings format if it is limited to the expected maximum length. Also, it would reject an attempted update with data that is too long to be a valid value. The only benefit is to accommodate a future change to allow "hitherto unknown precisions", though it shouldn't be too painful to just change the length in the event of such an unlikely requirement.

Leave a comment on “Multiple Tables!? Why bother?”

Log In or post as a guest

Replying to comment #:

Log Out

« Return to Article