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
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
read
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
2011/1/20 swagat.le...@accenture.com:
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
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
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,
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
-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, that still doesn't make
On 20 January 2011 14:32, Dotan Cohen dotanco...@gmail.com 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
On Thu, Jan 20, 2011 at 17:00, Richard Quadling rquadl...@gmail.com 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
On Thu, Jan 20, 2011 at 18:20, Dotan Cohen dotanco...@gmail.com wrote:
On Thu, Jan 20, 2011 at 17:00, Richard Quadling rquadl...@gmail.com 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
On Thu, Jan 20, 2011 at 17:22, Jerry Schwartz je...@gii.co.jp 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!
On Thu, Jan 20, 2011 at 17:22, Peter Brawley
peter.braw...@earthlink.net 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
On 20 January 2011 16:20, Dotan Cohen dotanco...@gmail.com wrote:
On Thu, Jan 20, 2011 at 17:00, Richard Quadling rquadl...@gmail.com 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
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
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
uuid()
Krishna
On Fri, Jan 21, 2011 at 12:02 AM, Anthony Pace anthony.p...@utoronto.cawrote:
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
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
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
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
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
On Thu, Jan 20, 2011 at 19:21, Richard Quadling rquadl...@gmail.com 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
On Thu, Jan 20, 2011 at 20:50, David Hutto smokefl...@gmail.com 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.
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're
On Thu, Jan 20, 2011 at 21:24, David Hutto smokefl...@gmail.com 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
On Thu, Jan 20, 2011 at 2:26 PM, Dotan Cohen dotanco...@gmail.com wrote:
On Thu, Jan 20, 2011 at 21:24, David Hutto smokefl...@gmail.com 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
-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 setting up
On Thu, Jan 20, 2011 at 2:40 PM, Jerry Schwartz je...@gii.co.jp 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
-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
On Thu, Jan 20, 2011 at 21:40, Jerry Schwartz je...@gii.co.jp 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
On Thu, Jan 20, 2011 at 7:00 AM, Richard Quadling rquadl...@gmail.comwrote:
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
On Thu, Jan 20, 2011 at 22:05, David Harkness davi...@highgearmedia.com 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
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
On Thu, Jan 20, 2011 at 12:21 PM, Dotan Cohen dotanco...@gmail.com 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
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()
[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) then it looks
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:
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:
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 column-name
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
40 matches
Mail list logo
