Hey,
I think that if you use the containable-behaviour (like I do with all
my models...) you can decide everywhere if you want to grab the user-
relations or not. So this would not be a problem, and there would be
only few actions and sections of the programm that would involve the
user-realtions
As I said, it depends on number of records. And how extensively you
use this table. If almost each user-related query involve this table
much better have straight JOIN condition then OR in it.
On Aug 29, 4:34 am, Pablo Viojo wrote:
> Based on my own experience using medium-sized tables the "or s
You shouldn't worry about it. IN statements are slower than OR and
Cake uses them constantly. If you really want to optimize your app,
optimize your controller and model logic, not the database queries.
--~--~-~--~~~---~--~~
You received this message because you are
Eh not so much. If you have a friends list it should be paginated and
even then it would be limited, so the query count wouldnt get to
high.
I currently run many sites with these features and its all fine.
--~--~-~--~~~---~--~~
You received this message because you
Based on my own experience using medium-sized tables the "or solution" is
slower than "replicating data solution"
Just my 2 cents.
Regards,
Pablo Viojo
pvi...@gmail.com
http://pviojo.net
¿Que necesitas?
http://needish.com
On Fri, Aug 28, 2009 at 2:35 AM, Miles J wrote:
>
> Your calling a few
It depends on table size. If you have many users and many friends
relations between them it matters. When you test on 10 users such
query is immediate of course.
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"CakePH
1. If friends system is not mutual 2 records are needed.
2. Even for mutual system "OR" in query is more expensive then 3-int
row in DB.
On Aug 28, 9:45 am, Miles J wrote:
> @DigitalDude - Yes thats correct.
>
> @Pablo - No its not, it doesn't make a difference in overhead at all.
> Also by inse
Your calling a few OR queries on a page, its not going to cause any
slow performance.
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"CakePHP" group.
To post to this group, send email to cake-php@googlegroups.com
To
@DigitalDude - Yes thats correct.
@Pablo - No its not, it doesn't make a difference in overhead at all.
Also by inserting 2 rows your causing overhead and unneeded rows in
the database.
Heres an example of one of my methods in my Friend model.
/**
* Checks to see if two users are friends
* @p
In the particular case of a friends table I recommend to insert two records
for each relation. It's faster to read (remember 90% reads, 10% inserts) :)
,
Pablo Viojo
pvi...@gmail.com
http://pviojo.net
¿Que necesitas?
http://needish.com
On Thu, Aug 27, 2009 at 12:33 PM, Miles J wrote:
>
> No
I don't recommend this approach because if you want to know all user 1
friends yo must do something like
user_id_1=1 or user_id_2=1 and thats an overhead (and you need two indexes
for that)
if you have something like:
Table friends:
id user1_id user2_id
1 12
1 2
Take a look at http://needish.com It's cakephp based :)
Regards,
Pablo Viojo
pvi...@gmail.com
http://pviojo.net
¿Que necesitas?
http://needish.com
On Wed, Aug 26, 2009 at 7:23 PM, DigitalDude
wrote:
>
> Hey,
>
> I'm wondering if it would be possible to build up a small a medium
> social netwo
Hey,
ah ok I think we both mean the same thing, but I forgot that the
relation is not only by one side, but by two sides.
So a simple example would look like this:
Table friends:
id user1_id user2_id
1 12
2 52
3 31
4 41
5
Not necessarily. If you are doing a friend system, the table would
look like so:
friends: id, user1_id, user2_id
And 1 row would be for both user1 and user2, instead of adding 2 rows
for each user.
--~--~-~--~~~---~--~~
You received this message because you are su
Hey,
ok these infos sound nice, the fact with the multiple read-db's is one
I haven't heard of but I'll gather all required info on that topic.
But to stay more practical, how would one realise a friend-list like
facebook or the other big networks? Is a join-table really a good
approach to reali
A single DB table with 500,000 records is not a problem, as long as
you're using a decent DB engine. I've used both Postgres and MySQL for
tables with several million records. Just make sure that you use the
DB's optimisation for large tables (eg. indexes, etc.)
On Wed, Aug 26, 2009 at 7:23 PM,
D
Cake can handle it... what you are really asking is wether your server
can handle it without any type of load-balancing. This is a much
harder question to answer since it would depend on many factors.
The reason Cake is a good framework for your situation is that it is
designed to help you out if
Hey,
I'm wondering if it would be possible to build up a small a medium
social network, just testwise, with CakePHP.
Let's say we would have approx 50.000 users and the could connect to
each other, could Cake and the DB handle those masses of users and
information?
How would it be pissible to s
18 matches
Mail list logo
