"I've run up on the rock of a binary (meaning: indecipherable) field."
SELECT hex(some_binary_field) FROM table;
Solved.
The information contained in this transmission may contain privileged and
confidential information. It is intended only for the use of
y 2009 09:53:58 -0400
To: Ilia KATZ
From: Fish Kungfu
Cc: mysql@lists.mysql.com
Subject: Re: MAC address as primary key - BIGINT or CHAR(12)
Message-ID:
--001636e90cddd7f9c70469dfa8fe
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Since MAC addreses als
Store as CHAR(12), not VARCHAR because they are ALWAYS a fixed length. It
saves space and is faster to index/lookup.
If you're using IPv4 only
then stick with CHAR(12).
elseif you think you'll go to IPv6 then
if large dataset (> 1M rows say),
plan for it now as
I agree, and didn't mean to say that I disagreed. This is certainly one of the
top five principles to follow, imo. Too many times, while trouble-shooting,
I've run up on the rock of a binary (meaning: indecipherable) field.
What is the cost of including the binary representation (for indexing)
er.
>
> I'll be interested in the answer, though, from someone with experience.
>
> -- Pete Wilson
> http://www.pwilson.net/
>
>
> --- On Thu, 5/14/09, Jim Lyons wrote:
>
> > From: Jim Lyons
> > Subject: Re: MAC address as primary key - BIGINT or CHAR(12)
>
be interested in the answer, though, from someone with experience.
-- Pete Wilson
http://www.pwilson.net/
--- On Thu, 5/14/09, Jim Lyons wrote:
> From: Jim Lyons
> Subject: Re: MAC address as primary key - BIGINT or CHAR(12)
> To: "Ilia KATZ"
> Cc: mysql@lists.mysql.
Definitely CHAR (or VARCHAR).
If the format of a MAC address changes at all, you could be in real
trouble. Also, if a MAC address can have a leading 0 (I don't know anything
about MAC addresses), then storing it as some sort of number could lose
that.
This is a general rule for me. A field migh
On Thu, 14 May 2009, Ilia KATZ wrote:
Hi.
Currently I have a table:
1. MAC address defined as BIGINT
2. MAC address set as primary key
Should I consider changing it to CHAR(12)?
Replies will be appreciated.
Ilia
Hi
It depends. You may convert the MAC address to a decimal integer and store
6th byte
the last 2 bytes (of the BIGINT) left unused.
Ilia
From: Fish Kungfu [mailto:fish.kun...@gmail.com]
Sent: Thursday, May 14, 2009 3:54 PM
To: Ilia KATZ
Cc: mysql@lists.mysql.com
Subject: Re: MAC address as primary key - BIGINT or CHAR(12
You might even want to plan for longer MAC addresses. I don't follow
developments in that area, but they had to go from IP4 to IP6 and they might
have to introduce longer MAC addresses.
It isn't hard to change a MySQL field definition, but your applications
would be more of a problem.
>-Origi
On Thursday 14 May 2009 09:53:58 am Fish Kungfu wrote:
> Since MAC addreses also contain letters, BIGINT wouldn't work. So, yes, I
> would say go with CHAR(12).
>
> On May 14, 2009 9:43 AM, "Ilia KATZ" wrote:
>
> Hi.
> Currently I have a table:
> 1. MAC address defined as BIGINT
> 2. MAC address
Since MAC addreses also contain letters, BIGINT wouldn't work. So, yes, I
would say go with CHAR(12).
On May 14, 2009 9:43 AM, "Ilia KATZ" wrote:
Hi.
Currently I have a table:
1. MAC address defined as BIGINT
2. MAC address set as primary key
Should I consider changing it to CHAR(12)?
Replies
12 matches
Mail list logo
