Re: MySQL Workbench ALTER VIEW bug? when using hexadecimal values

On 4/25/2016 3:59 AM, djburbridge_at_gmail.com wrote:
> Anyway, thanks for your response Jerry.
>
> Indeed - though the definition of "multiple values" here is probably open to interpretation. Is a datetime field non-normalised because it contains a day and a month and a year and an hour and a minute and a second?
>

That depends on the usage. If you're going to be regularly using the individual fields, i.e. looking at the 14th of every month or 13:00 every day, then it might be better to look at it as separate fields. However, this also precludes easy use of the the date and time functions. You have to decide based on how the data will be used.

When normalizing a database, how the data is used is usually more important than what the data is.

> In my case, the 96-bit field is a code, as read (from an RFID tag as it happens). So I store the code, *as read*, in a single field in a table, and then do the decoding via a view on that table. This enables me to manipulate the various encoded values in different ways. If I change the way in which I manipulate the value, or add extra conditions, I can (rather, should) just be able to change the view code without changing the underlying table or its data.
>

In this case you are using it as multiple values instead of a single one, so your database fails the 1NF test.

> In a more generalised sense, I suspect hex codes in a view may always get truncated, though I need to demonstrate that. If so, I'm a little surprised if no-one's found it yet! Then I'll see about reporting it.
>

As I said - it very well could be a bug. But I also think people who properly normalize their databases would not see it.

-- 
==================
Remove the "x" from my email address
Jerry Stuckle
jstucklex_at_attglobal.net
==================