I have to say, something similar was my first thought, too - you never
mention uuid in your original post. As already stated, uuid() should be a
Universal Unique IDentifier. It's afaik a random 128-bit number; given the
space to choose from it should be rather unique. I have to admit that I'm
not e
Remember, the InnoDB table has a full table lock now since it is doing and
ALTER TABLE.
You may want to kill it and try this instead:
In this example, the table with 12M rows is called BigTable
1) CREATE TABLE BigTable2 LIKE BigTable;
2) ALTER TABLE BigTable MODIFY COLUMN VARCHAR();
3) INSERT I
Hi,
I have an InnoDB with 12 millions of data. For some reason I need to alter the
table structure by expanding the varchars value. It's been an hour and slow
down the performance. Is it safe to kill the process? Thanks.
Willy
--
MySQL General Mailing List
For list archives: http://lists.mysql
My concern is exactly with adding new nodes. There
is no incrementor (++i) in SQL, so knowingly coding a solution that
will require incrementing two fields in half the database rows seems
irresponsible.
Yes, and an edge list model may perform better in other respects too:
http://www.artfulsoftw
>> [JS] I disagree. The method I proposed can be extended to any depth, and
>> any
>> leaf or branch can be retrieved with a single query.
>>
>
>I suppose for retrievals this structure has advantages, but unless
>MySQL has a ++ operator (or better yet, one that adds or subtracts 2
>from an int) th
http://www.mysqlperformanceblog.com/2007/03/13/to-uuid-or-not-to-uuid/
> -Original Message-
> From: Krishna Chandra Prajapati [mailto:prajapat...@gmail.com]
> Sent: Thursday, January 20, 2011 10:45 AM
> To: Anthony Pace
> Cc: mysql.
> Subject: Re: best way to have a unique key
>
> uuid(
On Thu, Jan 20, 2011 at 12:21 PM, Dotan Cohen wrote:
> I understood that. My concern is exactly with adding new nodes. There
> is no incrementor (++i) in SQL, so knowingly coding a solution that
> will require incrementing two fields in half the database rows seems
> irresponsible.
>
It only req
I should have read more carefully.. I apologize for my snap response.
At a guess: as I recall, under M$ SQLServer the typical (only?) form
of unique identifier used is something very UUID-like. MY information
might be dated. I was certified as a SQL Server administrator perhaps
12 years agoI wo
On Thu, Jan 20, 2011 at 22:05, David Harkness wrote:
> Thanks for the link. That article proposes an interesting way to organize
> the categories. Have you implemented this in the wild? Clearly the design
> would work as it's pretty simple, and I like that it removes the need for
> recursive queri
On Thu, Jan 20, 2011 at 7:00 AM, Richard Quadling wrote:
> I'd recommend using a nested set approach for the tags
> (http://dev.mysql.com/tech-resources/articles/hierarchical-data.html
> gives a good explanation on the issues and methodology of nested
> sets).
>
Thanks for the link. That article
On Thu, Jan 20, 2011 at 21:40, Jerry Schwartz wrote:
>>Thanks. I prefer the "parent tag" field, though, I feel that it is
>>more flexible.
>>
>>
> [JS] I disagree. The method I proposed can be extended to any depth, and any
> leaf or branch can be retrieved with a single query.
>
I suppose for re
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
What conflicts are you expecting? according to the documentation:
A UUID is designed as a number that is globally unique in space and
time. Two calls to UUID() are expected to generate two different
values, even if these calls are performed on two sep
On Thu, Jan 20, 2011 at 2:40 PM, Jerry Schwartz wrote:
>>-Original Message-
>>From: Dotan Cohen [mailto:dotanco...@gmail.com]
>>Sent: Thursday, January 20, 2011 11:25 AM
>>To: Jerry Schwartz
>>Cc: mysql.; php-general.
>>Subject: Re: Organisational question: surely someone has implemented m
>-Original Message-
>From: Dotan Cohen [mailto:dotanco...@gmail.com]
>Sent: Thursday, January 20, 2011 11:25 AM
>To: Jerry Schwartz
>Cc: mysql.; php-general.
>Subject: Re: Organisational question: surely someone has implemented many
>Boolean values (tags) and a solution exist
>
>
>> As for
On Thu, Jan 20, 2011 at 2:26 PM, Dotan Cohen wrote:
> On Thu, Jan 20, 2011 at 21:24, David Hutto wrote:
>>> Is this a troll? Am I about to be baited?
>>
>> Baited to deploy what is designed to the consumer's specification?
>> Surely. From what is wanted to what is needed. Troll on that.
>
> Actua
On Thu, Jan 20, 2011 at 21:24, David Hutto wrote:
>> Is this a troll? Am I about to be baited?
>
> Baited to deploy what is designed to the consumer's specification?
> Surely. From what is wanted to what is needed. Troll on that.
Actually, I'm the customer! But assuming that a customer exists, th
> Is this a troll? Am I about to be baited?
Baited to deploy what is designed to the consumer's specification?
Surely. From what is wanted to what is needed. Troll on that.
>
> --
> Dotan Cohen
>
> http://gibberish.co.il
> http://what-is-what.com
>
--
The lawyer in me says argue...even if you'
On Thu, Jan 20, 2011 at 20:50, David Hutto wrote:
> Pseudo = Design Algorithm
> Design Algorithm = Actual Code
> Actual Code = Alterable db tables
> Alterable db tables = manipulated data through the app interface with data
>
> --
> The lawyer in me says argue...even if you're wrong. The scientist
On Thu, Jan 20, 2011 at 19:21, Richard Quadling wrote:
>> That is terrific, at least the first half. The second half, with the
>> Venn diagrams, is awkward!
>
> When you get heavily nested data, the adjacent set model (where you
> have a parentid for every uniqueid), you very quickly get into
> co
Although I did berate you for your obvious cheek, I will of course
complement the acuteness of your response.
On 1/20/2011 2:10 PM, Anthony Pace wrote:
Dude, come on. I know that all primary keys have to be unique;
however, I was obviously referring to the use of uuid over auto
incrementation
I know of uuid() my problem is that there can be conflicts when copying
the DB to a different machine, or working with sections of the db on
different machines for load balancing.
On 1/20/2011 1:44 PM, Krishna Chandra Prajapati wrote:
> Please keep in mind this variable will also be displayed
Dude, come on. I know that all primary keys have to be unique; however,
I was obviously referring to the use of uuid over auto incrementation.
On 1/20/2011 1:36 PM, Michael Dykman wrote:
It is axiomatic in the relational model that a primary must be unique.
This is not a quirk put forth by y
Pseudo = Design Algorithm
Design Algorithm = Actual Code
Actual Code = Alterable db tables
Alterable db tables = manipulated data through the app interface with data
--
The lawyer in me says argue...even if you're wrong. The scientist in
me... says shut up, listen, and then argue. But the lawyer
uuid()
Krishna
On Fri, Jan 21, 2011 at 12:02 AM, Anthony Pace wrote:
> Due to certain reasons, the company I am doing business with has decided
> that the primary key, for an orders table, be a unique key; however, I don't
> like the possibility of it conflicting if moved to another machine.
>
>
Due to certain reasons, the company I am doing business with has decided
that the primary key, for an orders table, be a unique key; however, I
don't like the possibility of it conflicting if moved to another machine.
What are some pitfalls of using a unique key, that is generated by a
server
I cannot agree more with the others about using a join table. While it's
tempting to go with your first solution due to fear of performance issues,
you can usually address performance issues with a technical solution.
Addressing problems that arise from a constraining design choice is much
more dif
On 20 January 2011 16:20, Dotan Cohen wrote:
> On Thu, Jan 20, 2011 at 17:00, Richard Quadling wrote:
>> I'd have my items table, my tags table and a join table for the two.
>> My join table is really simple. UniqueID, ItemID, TagID.
>>
>
> Yes, that is the first approach that I mentioned. It loo
On Thu, Jan 20, 2011 at 17:22, Peter Brawley
wrote:
> I'd exclude (1) because new tags require restructuring the table, (2)
> and (3) because they break a cardinal rule of design and will be a mess
> to query, leaving ...
>
> 4) Standard many-many bridge table:
> mysql> CREATE TABLE items_tags (
On Thu, Jan 20, 2011 at 17:22, Jerry Schwartz wrote:
> I think the canonical way would be to have one table for your items, one table
> for your tags, and one table for your tag assignments.
>
Thank you, I do agree that this is the best way. Other posters seem to
agree as well!
> Using an ever-
On Thu, Jan 20, 2011 at 18:20, Dotan Cohen wrote:
> On Thu, Jan 20, 2011 at 17:00, Richard Quadling wrote:
>> I'd have my items table, my tags table and a join table for the two.
>> My join table is really simple. UniqueID, ItemID, TagID.
>>
>
> Yes, that is the first approach that I mentioned. I
On Thu, Jan 20, 2011 at 17:00, Richard Quadling wrote:
> I'd have my items table, my tags table and a join table for the two.
> My join table is really simple. UniqueID, ItemID, TagID.
>
Yes, that is the first approach that I mentioned. It looks to be a
good compromise.
> I'd recommend using a
On 20 January 2011 14:32, Dotan Cohen wrote:
> I am designing an application that make heavy usage of one-to-many
> tags for items. That is, each item can have multiple tags, and there
> are tens of tags (likely to grow to hundreds). Most operation on the
> database are expected to be searches for
>-Original Message-
>From: Joerg Bruehe [mailto:joerg.bru...@oracle.com]
>Sent: Thursday, January 20, 2011 6:54 AM
>To: Jerry Schwartz
>Cc: mysql@lists.mysql.com
>Subject: Re: Can't read dir of '.' (errno: 13)
>
>Hi!
>
>
>Jerry Schwartz wrote:
>> [[...]]
>>
>>> [[...]]
>>>
>> [JS] Sorry, th
I think the canonical way would be to have one table for your items, one table
for your tags, and one table for your tag assignments.
CREATE TABLE items (
item_id INT(11) AUTO-INCREMENT PRIMARY KEY,
item_name VARCHAR(100) NOT NULL KEY,
...
);
CREATE TABLE tags (
tag_id INT(11) AUTO-INCREMENT PRI
I'd exclude (1) because new tags require restructuring the table, (2)
and (3) because they break a cardinal rule of design and will be a mess
to query, leaving ...
4) Standard many-many bridge table:
mysql> CREATE TABLE items_tags (
id INT NOT NULL AUTO_INCREMENT PRIMARY KEY,
itemID int,
t
I am designing an application that make heavy usage of one-to-many
tags for items. That is, each item can have multiple tags, and there
are tens of tags (likely to grow to hundreds). Most operation on the
database are expected to be searches for the items that have a
particular tag. That is, users
2011/1/20 :
> Hi,
I lack on knowledge about "Informatica" software. But if you are
really sure that the problem is not on source data and not on backend
configuration, then it is just in the middle. :-)
I will be more specific (at least, as far as I can be). In a MySQL, a
charset is negotiated o
Hi,
Currently we are trying to load Unicode data encoded in UTF-8 to mySQL but the
data is getting corrupted during load. Loading is done through Informatica (ETL
Tool) and data is properly extracted and interpreted by Informatica but still
it is failing to load it in the correct format. When w
Hi!
Jerry Schwartz wrote:
> [[...]]
>
>> [[...]]
>>
> [JS] Sorry, that still doesn't make sense to em. To authenticate the user,
> mysqld needs to read the mysql database. That is also where the databases are
> listed (in `mysql`.`db`). If the daemon can read `mysql`.`user`, why can't it
> re
On 2011-1-16 20:22, Jørn Dahl-Stamnes wrote:
Hello,
I got a table that store information about which photo-albums that a client is
viewing. I want to get the N last visited albums and use the query:
mysql> select album_id, updated_at, created_at from album_stats order by
updated_at desc limit
40 matches
Mail list logo
