till i think i absolutely need to trade-off easier and less
complicated code, better db structure (from a relational perspective)
and generally less head aches for speed, i think i'll stick with the
joins for now!...;)
the thought of denormalization really doesnt appeal to me...
--
Philip Semanchuk wrote:
Well OK, but that's a very different argument. Yes, joins can be
expensive. They're often still the best option, though. The first step
people usually take to get away from joins is denormalization which can
improve SELECT performance at the expense of slowing down
On Wed, 2010-03-03 at 20:39 +0100, mk wrote:
Hello Tim,
Pardon the questions but I haven't had the need to use denormalization
yet, so:
IOW you basically merged the tables like follows?
CREATE TABLE projects (
client_id BIGINT NOT NULL,
project_id BIGINT NOT NULL,
cost
On Wed, 2010-03-03 at 16:23 -0500, D'Arcy J.M. Cain wrote:
On Wed, 03 Mar 2010 20:39:35 +0100
mk mrk...@gmail.com wrote:
If you denormalise the table, and update the first index to be on
(client_id, project_id, date) it can end up running far more quickly -
Maybe. Don't start with
D'Arcy J.M. Cain wrote:
I keep seeing this statement but nothing to back it up. I have created
many apps that run on Python with a PostgreSQL database with a fully
normalized schema and I can assure you that database joins were never
my problem unless I made a badly constructed query or left
On Wed, 2010-03-03 at 17:26 +0100, mk wrote:
So there *may* be some evidence that joins are indeed bad in
practice.
If someone has smth specific/interesting on the subject, please post.
I have found joins to cause problems in a few cases - I'm talking about
relatively large tables though -
mk wrote:
D'Arcy J.M. Cain wrote:
I keep seeing this statement but nothing to back it up. I have created
many apps that run on Python with a PostgreSQL database with a fully
normalized schema and I can assure you that database joins were never
my problem unless I made a badly constructed
On Mar 3, 2010, at 11:26 AM, mk wrote:
D'Arcy J.M. Cain wrote:
I keep seeing this statement but nothing to back it up. I have
created
many apps that run on Python with a PostgreSQL database with a fully
normalized schema and I can assure you that database joins were never
my problem unless
Hello Tim,
Pardon the questions but I haven't had the need to use denormalization
yet, so:
Tim Wintle wrote:
/* Table A*/
CREATE TABLE TableA (
project_id BIGINT NOT NULL,
cost INT,
date DATETIME,
PRIMARY KEY (project_id, date)
);
/* Table projects */
CREATE TABLE
Philip Semanchuk wrote:
So there *may* be some evidence that joins are indeed bad in practice.
If someone has smth specific/interesting on the subject, please post.
It's an unprovable assertion, or a meaningless one depending on how one
defines the terms. You could also say there *may* be
On Wed, 03 Mar 2010 20:39:35 +0100
mk mrk...@gmail.com wrote:
If you denormalise the table, and update the first index to be on
(client_id, project_id, date) it can end up running far more quickly -
Maybe. Don't start with denormalization. Write it properly and only
consider changing if
On Mar 3, 2010, at 3:58 PM, mk wrote:
Philip Semanchuk wrote:
So there *may* be some evidence that joins are indeed bad in
practice. If someone has smth specific/interesting on the subject,
please post.
It's an unprovable assertion, or a meaningless one depending on how
one defines the
In article mailman.99.1267513003.23598.python-l...@python.org,
D'Arcy J.M. Cain da...@druid.net wrote:
Put as much memory as you can afford/fit into your database server.
It's the cheapest performance boost you can get. If you have a serious
application put at least 4GB into your dedicated
On Feb 25, 12:21 pm, Martin P. Hellwig martin.hell...@dcuktec.org
wrote:
On 02/25/10 10:26, simn_stv wrote:
cut what i am concerned about is scalability and
efficiency, well, as far as the 'core' is concerned.
would python be able to manage giving me a solid 'core' and will i be
able to
On Feb 25, 5:18 pm, D'Arcy J.M. Cain da...@druid.net wrote:
On Thu, 25 Feb 2010 15:29:34 +
Martin P. Hellwig martin.hell...@dcuktec.org wrote:
On 02/25/10 13:58, D'Arcy J.M. Cain wrote:
On Thu, 25 Feb 2010 02:26:18 -0800 (PST)
cut
Our biggest problem was in
a network heavy
On Feb 25, 5:18 pm, D'Arcy J.M. Cain da...@druid.net wrote:
On Thu, 25 Feb 2010 15:29:34 +
Martin P. Hellwig martin.hell...@dcuktec.org wrote:
On 02/25/10 13:58, D'Arcy J.M. Cain wrote:
On Thu, 25 Feb 2010 02:26:18 -0800 (PST)
cut
Our biggest problem was in
a network heavy
On Feb 26, 10:32 am, mdipierro massimodipierr...@gmail.com wrote:
100,000 hits a day is not a low. I get that some day on my web server
without problem and without one request dropped.
Most frameworks web2py, Django, Pylons can handle that kind of load
since Python is not the bottle neck.
On Mon, 1 Mar 2010 04:11:07 -0800 (PST)
simn_stv nany...@googlemail.com wrote:
All of the above (and much more complexity not even discussed here) was
handled by Python code and database manipulation. There were a few
bumps along the way but overall it worked fine. If we were using C or
On Feb 26, 10:19 am, Diez B. Roggisch de...@nospam.web.de wrote:
Am 26.02.10 05:01, schrieb D'Arcy J.M. Cain:
On Fri, 26 Feb 2010 01:12:00 +0100
Diez B. Roggischde...@nospam.web.de wrote:
That better way turned out to asynchronous update transactions. All we
did was keep feeding
On Mon, 1 Mar 2010 06:42:28 -0800 (PST)
simn_stv nany...@googlemail.com wrote:
On Feb 26, 10:19 am, Diez B. Roggisch de...@nospam.web.de wrote:
So when you talk about ACKs, you don't mean these on the TCP-level
(darn, whatever iso-level that is...), but on some higher level?
i think its on
On Mar 1, 6:32 am, simn_stv nany...@googlemail.com wrote:
...
You have to follow some tricks:
1) have the web server serve static pages directly and set the pragma
cache expire to one month
2) cache all pages that do not have forms for at least few minutes
3) avoid database joins
but
On Mon, 1 Mar 2010 16:20:06 -0800 (PST)
mdipierro massimodipierr...@gmail.com wrote:
Joins are the bottle neck of most web app that relay on relational
databases. That is why non-relational databases such as Google App
Engine, CouchDB, MongoDB do not even support Joins. You have to try to
Am 26.02.10 05:01, schrieb D'Arcy J.M. Cain:
On Fri, 26 Feb 2010 01:12:00 +0100
Diez B. Roggischde...@nospam.web.de wrote:
That better way turned out to asynchronous update transactions. All we
did was keep feeding updates to the remote site and forget about ACKS.
We then had a second process
100,000 hits a day is not a low. I get that some day on my web server
without problem and without one request dropped.
Most frameworks web2py, Django, Pylons can handle that kind of load
since Python is not the bottle neck.
You have to follow some tricks:
1) have the web server serve static
hello people, i have been reading posts on this group for quite some
time now and many, if not all (actually not all!), seem quite
interesting.
i plan to build an application, a network based application that i
estimate (and seriously hope) would get as many as 100, 000 hits a day
(hehe,...my dad
simn_stv wrote:
hello people, i have been reading posts on this group for quite some
time now and many, if not all (actually not all!), seem quite
interesting.
i plan to build an application, a network based application that i
estimate (and seriously hope) would get as many as 100, 000 hits a
On 02/25/10 10:26, simn_stv wrote:
cut
what i am concerned about is scalability and
efficiency, well, as far as the 'core' is concerned.
would python be able to manage giving me a solid 'core' and will i be
able to use python provide any API i would like to implement?...
cut
Python isn't the
On Thu, 2010-02-25 at 02:26 -0800, simn_stv wrote:
i plan to build an application, a network based application that i
estimate (and seriously hope) would get as many as 100, 000 hits a day
(hehe,...my dad always told me to 'AIM HIGH' ;0), not some 'facebook'
or anything like it, its mainly for
On Feb 25, 12:13 pm, Steve Holden st...@holdenweb.com wrote:
simn_stv wrote:
hello people, i have been reading posts on this group for quite some
time now and many, if not all (actually not all!), seem quite
interesting.
i plan to build an application, a network based application that i
simn_stv wrote:
i plan to build an application, a network based application that i
estimate (and seriously hope) would get as many as 100, 000 hits a day
(hehe,...my dad always told me to 'AIM HIGH' ;0), not some 'facebook'
or anything like it, its mainly for a financial transactions which
gets
On Thu, 25 Feb 2010 02:26:18 -0800 (PST)
simn_stv nany...@googlemail.com wrote:
i plan to build an application, a network based application that i
estimate (and seriously hope) would get as many as 100, 000 hits a day
That's nothing. I ran a financial type app on Python that sometimes
hit
On 02/25/10 13:58, D'Arcy J.M. Cain wrote:
On Thu, 25 Feb 2010 02:26:18 -0800 (PST)
cut
Our biggest problem was in
a network heavy element of the app and that was low level TCP/IP stuff
that rather than being Python's problem was something we used Python to
fix.
cut
Out off interest, could
On Thu, 25 Feb 2010 15:29:34 +
Martin P. Hellwig martin.hell...@dcuktec.org wrote:
On 02/25/10 13:58, D'Arcy J.M. Cain wrote:
On Thu, 25 Feb 2010 02:26:18 -0800 (PST)
cut
Our biggest problem was in
a network heavy element of the app and that was low level TCP/IP stuff
that rather
In article 5cd38064-34d6-40d3-b3dc-2c853fc86...@i39g2000yqm.googlegroups.com,
simn_stv nany...@googlemail.com wrote:
i plan to build an application, a network based application that i
estimate (and seriously hope) would get as many as 100, 000 hits a day
(hehe,...my dad always told me to 'AIM
In article mailman.244.1267114628.4577.python-l...@python.org,
D'Arcy J.M. Cain da...@druid.net wrote:
The problem had to do with the way TCP/IP works, especially closer to
the core. Our provider was collecting data and sending it only after
filling a buffer or after a timeout. The timeout
On 02/25/10 16:18, D'Arcy J.M. Cain wrote:
cut working around ISP's with braindead network configurations
Very interesting, I had a similar kind of problem (a network balancer
that doesn't balance small tcp packages too well) and solved it by
wrapping the TCP package in UDP. UDP was treated
That better way turned out to asynchronous update transactions. All we
did was keep feeding updates to the remote site and forget about ACKS.
We then had a second process which handled ACKS and tracked which
packets had been properly transferred. The system had IDs on each
update and retries
On Fri, 26 Feb 2010 01:12:00 +0100
Diez B. Roggisch de...@nospam.web.de wrote:
That better way turned out to asynchronous update transactions. All we
did was keep feeding updates to the remote site and forget about ACKS.
We then had a second process which handled ACKS and tracked which
38 matches
Mail list logo
