On Fri, 2009-04-17 at 21:16 +0100, Martin P. Hellwig wrote:
> So in other words, just lay out the data which makes the most sense
> to
> you, the pain of recreating SQL like logic is there no matter what
> layout you choose.
I have to say that given the amount of pain most people seem to go
thro
Daniel Fetchinson wrote:
Thanks, this wikipedia entry was actually very useful as well as your
other comments.
Thanks again,
Daniel
Your welcome, I usually take quite a lot of effort into designing before
I start coding. One tool I found very helpful was DIA, especially the
UML section. Ha
On Apr 17, 3:16 pm, "Martin P. Hellwig"
wrote:
> Daniel Fetchinson wrote:
>
>
>
>
>
> > In an relational database setting you would have a table for artists,
> > a table for cd's and a table for songs and a table for comments where
> > people can comment on songs. All of this with obvious foreign
>> In an relational database setting you would have a table for artists,
>> a table for cd's and a table for songs and a table for comments where
>> people can comment on songs. All of this with obvious foreign keys.
>> Now you want to display on your website the total number of cd's, the
>> total
Daniel Fetchinson wrote:
In an relational database setting you would have a table for artists,
a table for cd's and a table for songs and a table for comments where
people can comment on songs. All of this with obvious foreign keys.
Now you want to display on your website the total number of cd'
On Thu, 2009-04-16 at 14:11 -0700, John Fabiani wrote:
> Daniel Fetchinson wrote:
>
> > Hi folks, I've come across many times the claim that 'joins are bad'
> > for large databases because they don't scale
>
> IMO that's bull...
OK. That makes four legs so far
> --
> http://mail.python.org
>> Well, I gave the concrete example of zoo/cage/animal/leg because this
>> *is* the business logic. I need to know for example the total number
>> of animals, this is pretty understandable if you have a zoo. Or you
>> mean that I should give another example?
>
> It might be the business logic but
on the more general point about exactly how to handle large data sets, i
found this article interesting -
http://highscalability.com/unorthodox-approach-database-design-coming-shard
andrew
--
http://mail.python.org/mailman/listinfo/python-list
Daniel Fetchinson wrote:
Well, I gave the concrete example of zoo/cage/animal/leg because this
*is* the business logic. I need to know for example the total number
of animals, this is pretty understandable if you have a zoo. Or you
mean that I should give another example?
It might be the busin
Daniel Fetchinson writes:
> Yes, sorry for using the wrong words, my question then is how do I
> solve a problem similar to my zoo/cage/animal/leg problem with
> distributed databases?
In the case of BigTable, you could write a suitable MapReduce task.
You might look at the Wikipedia articles abo
>> [off but interesting topic]
>
>
>> What would be the corresponding database layout that would scale and I
>> could get the total number of legs in the zoo or total number of
>> animals in the zoo without join(s)?
>>
>> Cheers,
>> Daniel
>>
>> [/off but interesting topic]
>>
>
> That all comes d
>> If you think that's bull, why do you think the google app engine or
>> bigtable doesn't support joins?
>
> Join is a relational database concept. Bigtable is not a relational
> database. Of course it does lookups, but they are not the same as
> relational joins.
True! I gave a use case that c
Hi folks, I've come across many times the claim that 'joins are bad'
for large databases because they don't scale
>>> IMO that's bull...
>>
>> If you think that's bull, why do you think the google app engine or
>> bigtable doesn't support joins?
>
> "Large database" is not synonymous with
Daniel Fetchinson writes:
> If you think that's bull, why do you think the google app engine or
> bigtable doesn't support joins?
Join is a relational database concept. Bigtable is not a relational
database. Of course it does lookups, but they are not the same as
relational joins.
--
http://mai
Robert Kern wrote:
...(snip)
"Large database" is not synonymous with "distributed database".
===
True!
And cross-code lookup tables can make otherwise very large 'bytes on
disk' rather small overall.
Z3 in common_names.dbf African Pygmy Zebra
Z3 i
On 2009-04-16 18:05, Daniel Fetchinson wrote:
Hi folks, I've come across many times the claim that 'joins are bad'
for large databases because they don't scale
IMO that's bull...
If you think that's bull, why do you think the google app engine or
bigtable doesn't support joins?
"Large databa
Daniel Fetchinson wrote:
[off but interesting topic]
What would be the corresponding database layout that would scale and I
could get the total number of legs in the zoo or total number of
animals in the zoo without join(s)?
Cheers,
Daniel
[/off but interesting topic]
That all comes down
>> Hi folks, I've come across many times the claim that 'joins are bad'
>> for large databases because they don't scale
>
> IMO that's bull...
If you think that's bull, why do you think the google app engine or
bigtable doesn't support joins?
Cheers,
Daniel
--
Psss, psss, put it down! - http:/
>> Hi folks, I've come across many times the claim that 'joins are bad'
>> for large databases because they don't scale.
>
> I think that means joins with very large result sets and lots of
> different values being matched on between the two tables. The usual
> use of a join in, say, web server pr
Daniel Fetchinson writes:
> Hi folks, I've come across many times the claim that 'joins are bad'
> for large databases because they don't scale.
I think that means joins with very large result sets and lots of
different values being matched on between the two tables. The usual
use of a join in,
John Fabiani wrote:
> Daniel Fetchinson wrote:
>
>> Hi folks, I've come across many times the claim that 'joins are bad'
>> for large databases because they don't scale
> IMO that's bull...
>> Okay, makes sense, we agree.
;)
--
http://mail.python.org/mailman/listinfo/python-list
Daniel Fetchinson wrote:
> Hi folks, I've come across many times the claim that 'joins are bad'
> for large databases because they don't scale
IMO that's bull...
--
http://mail.python.org/mailman/listinfo/python-list
In article ,
Aaron Brady wrote:
>
>Wait a second., how many legs in the zoo??
That's so you can find out how many to pull.
--
Aahz (a...@pythoncraft.com) <*> http://www.pythoncraft.com/
"If you think it's expensive to hire a professional to do the job, wait
until you hire an
On Apr 16, 1:45 pm, Daniel Fetchinson
wrote:
> [off but interesting topic]
>
> Hi folks, I've come across many times the claim that 'joins are bad'
> for large databases because they don't scale. Okay, makes sense, we
> agree. But what I don't get, although I watched a couple of online
> videos on
[off but interesting topic]
Hi folks, I've come across many times the claim that 'joins are bad'
for large databases because they don't scale. Okay, makes sense, we
agree. But what I don't get, although I watched a couple of online
videos on this topic (one by the creator of flickr who gave a talk
In message <[EMAIL PROTECTED]>, Dennis Lee
Bieber wrote:
> On Sun, 20 Jul 2008 18:43:03 -0700, "bruce" <[EMAIL PROTECTED]>
> declaimed the following in comp.lang.python:
>>
>> mysql cmd - select * from foo where dog like "%small%";
>>
>> sql ="""select * from foo where dog like "%%%s%%" """
>> c
update...
in using the mysql_query log function, i get the following query being
registered:
select * from foo where dog like "%'small'%"
so.. if i can figure out how to get rid of the "'" inside the "%" the query
should/will work...
thanks
Hi...
simple test
mysql cmd - select * from foo
Hi...
simple test
mysql cmd - select * from foo where dog like "%small%";
sql ="""select * from foo where dog like "%%%s%%" """
c.execute(sql, (var,))
the above doesn't work, and I can't seem to figure out how to display/print
out the sql as i't actually been excuted, so I can see where the is
28 matches
Mail list logo
