I think most mom and pop biz use a shared hosting provider, so their site
would be stitting on a server with 100 copies of Wordpress or whatever;
therefore those 100 installs need to be optimized.
On Tue, Mar 8, 2011 at 1:09 PM, Gary Mort wrote:
> On 3/7/2011 2:41 PM, Paul A Houle wrote:
>
>> O
On 3/7/2011 2:41 PM, Paul A Houle wrote:
On 3/5/2011 1:27 PM, Gary Mort wrote:
I am no longer convinced that the cpu cycles saved by using a numeric
id are sufficient to justify doing so with todays computers. By the
time you get to an app that is sizable enough to be looking to shave
those
On Mar 7, 2011, at 2:41 PM, Paul A Houle wrote:
> It's not cpu cycles that matter here, but I/O bandwidth, seek time, and
> RAM for cache on your database server.
...
> it's remarkably easy to put enough data into a database that you'll have
> performance problems, particularly if you're imp
On 3/5/2011 1:27 PM, Gary Mort wrote:
I am no longer convinced that the cpu cycles saved by using a numeric
id are sufficient to justify doing so with todays computers. By the
time you get to an app that is sizable enough to be looking to shave
those few microseconds, your going to be dealing
CPUs are some gosh darn fast, I suspect at one point all the rules of the
last 25 years will go out the door. Just throw your data here, who cares
about normailization, rules, joins, or anything. Just dump it here. We'll
figure it out.
I LOVE the SQLite things for iPhone.
So, how many people have
>> On 3/6/2011 10:26 PM, Matt Juszczak wrote:
>>> Yes, but most nosql databases aren't designed for durability or reliable
>>> persistence.
The MongoDB developers seem to be tackling this problem (and in general, seem
to be committed to make their db the best of both worlds). They recommend
al
On Mar 7, 2011, at 2:28 PM, Paul A Houle wrote:
> On 3/6/2011 10:26 PM, Matt Juszczak wrote:
>>
>> Yes, but most nosql databases aren't designed for durability or reliable
>> persistence. Remember -- one can always use MySQL as a "noSQL" DB by simply
>> de-normalizing, or applying the "schemal
On 3/6/2011 10:26 PM, Matt Juszczak wrote:
Yes, but most nosql databases aren't designed for durability or
reliable persistence. Remember -- one can always use MySQL as a
"noSQL" DB by simply de-normalizing, or applying the "schemaless" patch.
I've had a serious eye on mongodb, but I'd
At 6:46 PM -0500 3/6/11, David Krings wrote:
On 3/6/2011 3:46 PM, tedd wrote:
You won't have any "redundant" info if you use email as unique -- after all,
email *IS* unique.
Unique yes, but it can change.
If that is the case, then change it -- I don't see a problem. I do
see a problem IF on
I'm quite familiar with means of using MySQL in NoSQL ways, but what is this
"schemaless" patch you speak of?
Not sure if this was the one I used originally, but a quick google pulled
this one up:
http://www.igvita.com/2010/03/01/schema-free-mysql-vs-nosql/
___
On 3/6/11 10:26 PM, Matt Juszczak wrote:
This pretty much sums up why "nosql" databases have become so popular
lately.
Yes, but most nosql databases aren't designed for durability or
reliable persistence. Remember -- one can always use MySQL as a
"noSQL" DB by simply de-normalizing, or apply
This pretty much sums up why "nosql" databases have become so popular lately.
Yes, but most nosql databases aren't designed for durability or reliable
persistence. Remember -- one can always use MySQL as a "noSQL" DB by
simply de-normalizing, or applying the "schemaless" patch.
_
On Mar 6, 2011, at 6:46 PM, David Krings wrote:
> On 3/6/2011 3:46 PM, tedd wrote:
>> You won't have any "redundant" info if you use email as unique -- after all,
>> email *IS* unique.
> Unique yes, but it can change.
I think in Gary's original post, he was talking about having an alias table to
On 3/6/2011 3:46 PM, tedd wrote:
You won't have any "redundant" info if you use email as unique -- after all,
email *IS* unique.
Unique yes, but it can change. You'd need to change the primary key of a
record if a user wants to use a different email address. Not sure if that is a
smart thing
At 4:54 PM -0500 3/5/11, David Krings wrote:
On 3/4/2011 3:07 PM, D. J. Waletzky wrote:
The problem with eliminating "redundant" info in a user table is that it
may not scale terribly well. I always take care to give any user table
an auto_incremented row number/uid, because the user's handle an
On Mar 5, 2011, at 4:54 PM, David Krings wrote:
> Stick everything into one table and if it makes sense duplicate partial data
> in a different table to minimize joins. Not only are the queries much simpler
> then and get executed faster, figuring out what goes on is also much easier.
> As a si
On 3/4/2011 3:07 PM, D. J. Waletzky wrote:
The problem with eliminating "redundant" info in a user table is that it
may not scale terribly well. I always take care to give any user table
an auto_incremented row number/uid, because the user's handle and
e-mail, though unique, may change. Without a
On 3/4/2011 3:07 PM, D. J. Waletzky wrote:
The problem with eliminating "redundant" info in a user table is that it
may not scale terribly well. I always take care to give any user table
an auto_incremented row number/uid, because the user's handle and
e-mail, though unique, may change. Without a
On 3/4/2011 2:41 PM, Rob Marscher wrote:
Some nice thoughts. Thanks for sharing.
On Mar 4, 2011, at 2:30 PM, Gary Mort wrote:
Get rid of 2 of them. And the one that makes the most sense to keep is
username.
There's probably some sites where people don't even want to bother creating a
usern
On 3/4/2011 3:07 PM, D. J. Waletzky wrote:
I'd say that unless you have more than 4000 users (depending on the
limits of your db host) you can probably get away with keeping the
number of tables small and the numbers of columns somewhat high. It's
always best to run some sample queries to get a
On 3/4/2011 2:30 PM, Gary Mort wrote:
Oh, and get rid of that password as well. It doesn't need to be in
that table and because it is assumed to be there, I have to do some
really hackish things when one wants to authenticate in some other way.
I've kept the password in a separate tabl
The problem with eliminating "redundant" info in a user table is that it
may not scale terribly well. I always take care to give any user table
an auto_incremented row number/uid, because the user's handle and
e-mail, though unique, may change. Without an independent index
changing either of these
Some nice thoughts. Thanks for sharing.
On Mar 4, 2011, at 2:30 PM, Gary Mort wrote:
> Get rid of 2 of them. And the one that makes the most sense to keep is
> username.
There's probably some sites where people don't even want to bother creating a
username and just use an email address. But
After a number ofodd fights with user tables I'm coming the
conclusion that Mitch is right.
The typical user table starts with 3 bits of information:
A userid
A username
An email address.
A one way encrypted password
MaybeMAYBE some user status info...
And it demands that the first thr
24 matches
Mail list logo
