Help: Social Media based PHP book?

[Xenonsoft]

A mate of mine and I are embarking on social media creation. We've got most of it lined up in our heads, but he's struggling with lack of knowledge on how to create log-in pages in PHP, how many SQL database pulls he should be looking to do, best ways to do this, that and the other etc.

I said to him there must be a book out there that talks about the best practices with this sort of thing and would guide you through how to make a log-in or the like.

I've had a look on amazon.co.uk and amazon.com and it seems there is none, but I thought I would ask here aswell.

If anyone knows of such a book that deals in best practices of PHP and in particular something social-network orientated that would be fantastic.

 

[chrismitchell]

have you looked on smashing magazine Fred? They have loads of stuff on PHP and the like

 

[Xenonsoft]

Not yet, I didn't think they would be that specific. Will definitely check it out cheers Chris, I've been browsing a few larger more PHP specific forums for any golden nuggets

 

[mike_watts]

I've used a book called Dreamweaver MX Databases but it's old now there might be something on php and databases by O'reilly - they are quite good, or some sort of php/mysql cook book by them might help.

Dreamweaver does it automatically for you if you are using this or can invest in it.

Here are a few links:PHP Security Consortium: Password Hashing that might help.
You need to make sure that you encrypt the password in someway using MD5 (there is another way but cant remember) otherwise it will be viewable in plaintext inside the database: Never store passwords in a database!

 

[Xenonsoft]

Cheers Mike.

As I'm not the back-end coder I half understand you, which is a good start

We certainly encrypt the passwords, using a combination of md5 and sha.

What we're looking for is best practices etc. really. We've got the ability to build the site we want to, but we wont do it the way we should. By that I mean, too many SQL pulls etc.

We're looking for a book that will be able to help with this, so maybe my original post was a little misleading.

 

[darren]

Some more specific questions would be good

Login's only need 1 sql query to run to check if you are right or wrong. Hell.. if you are really good and need to reduce traffic, it only needs done once per session (if they continue to use the same username to try and login). But obviously each request needs to run a server side script.

As for an "overall" , this really depends on what you show on a page and what your database schema looks like.

i.e. if you have a table in your database called "users" and someone logs in, then you show them a "profile" page or similar that shows them information about themselves that you pulled all from this one table, then you only need one query. This is obviously not the way and very limited, but just an example.

If someone logged in and you showed them the same as what you see on a my " "* space page, then you are looking at much more queries as your schema should be more efficient.

* space as pun intended p)

But the real questions are .....

1. what does your database look like? (very important - should be well designed) (edit: and how many tables do you need to pull info from, how many joins can you do etc, memory load etc etc etc)
2. what do you want to show to the user on that particular page? or session (bigger sites)
3. What does your site hosting hardware look like?

The hardware that hosts your site (or in the case of your questions the database) should really dictate what you can do with it. (or how sloppy you can be)

If you have any particular questions, please ask. I will try to help.

If you need specialist advice, I charge by the hour


Its not possible for a book to answer your question, because it would depend on what scale you were building the site. Maybe a book on low/medium/enterprise level web applications would suit.

If you wanted to create something like facebook, imagine 100's of servers. (Not including database ones) and multiple teams of coders/tech to handle the code/servers. Also they are implemented on Weblogic/Websphere and the sites are written mostly in Java. So optimisation it paramount, as one line of unoptimised code could double (or n*) server workload

Darren

 

[Renniks]

Would it not be better to create the site, get it working, then work out how to minimise it. You arent working under a time limit, you arent working because you have to, you are creating a site which you want because you want it, and wills strive for perfection.

 

[darren]

Would it not be better to create the site, get it working, then work out how to minimise it. You arent working under a time limit, you arent working because you have to, you are creating a site which you want because you want it, and wills strive for perfection.

This is most certainly NOT the way to work on any project with any kind of scale to it. I can tell you from many years of having it drilled into me (Uni etc) and then working on lots of big projects; that what you get on paper before writig a line of code is THE most important.

Your documentation is paramount, the problem definition, requirements specification, database schema design etc should all be written and re-written many times before you start. This is also the key with clients. If you dont nail exactly what you are doing for a client before hand, when does the work stop? When they are satisfied? Then you are going to be there a long time

So for a site such as this (social networking and highly functional).. the most important factor is the Database Design. The reason for this is that the rest of the site is built around the flow of data. If you imagine My Space or Facebook for example. Each page yo visit is probably 75% (guess) made up of data pulled from the database and its many tables, columns, fields.

So... for example.. lets say you design the "users" table like this...

user_id
user_name
user_username
user_email
user_address
user_postcode
user_last_login

so now you go and code your site. But.. later on in the project you (or your client)decide that you would rather have a first name and second name , instead of one name. Do you see what I am getting at? This is quite a small and simple example, but it gets a hell of a lot more complicated.

For this example you would have to create two new columns (something like user_forename, user_surname) in the database and remove the user_name column, (if it was already running you would need to create a script that slit the names in the existing column etc - more work) Now think about your code. Throughout the whole site you have probaby used something like <?php print($user['user_name']); ?> and all of this would have to be changed.

On a larger scale site, this is not nice - and most certainly painful if the code has been sloppy.

 

[Xenonsoft]

Just had a quick skim and will post my thoughts later.

Cheers.

 

[Xenonsoft]

Some more specific questions would be good

Login's only need 1 sql query to run to check if you are right or wrong. Hell.. if you are really good and need to reduce traffic, it only needs done once per session (if they continue to use the same username to try and login). But obviously each request needs to run a server side script.

Hey Darren, cheers for putting the effort into helping me out.

Regarding the above, specific questions are slightly lacking currently mainly as the questions aren't coming from myself, but rather my business partner. He's the back-end coder and although I will be having input in all stages I'll often be trusting his knowledge over mine; and after-all, he'll code it.

Regarding the log-in script we're definitely going to use cookies and sessions (I'm assured they're slightly different) so that the username and password wont be needed to be pulled more than once in theory.

As for an "overall" , this really depends on what you show on a page and what your database schema looks like.

Agreed, this is certainly key. We're normalising the database to the third form as standard, but we'll have to make sure we're happy with how it looks before ploughing on. I've already written up some documentation on the front-end functionality we'll require and what we'll add-on after launch so hopefully that will leave us in good stead to work out exactly how we need to pull the data.

But the real questions are .....

1. what does your database look like? (very important - should be well designed) (edit: and how many tables do you need to pull info from, how many joins can you do etc, memory load etc etc etc)
2. what do you want to show to the user on that particular page? or session (bigger sites)

As above.

3. What does your site hosting hardware look like?

The hardware that hosts your site (or in the case of your questions the database) should really dictate what you can do with it. (or how sloppy you can be)

Well to start with on the alpha and private beta releases we will certainly be looking at shared hosting (we currently host with the reseller plan on fasthosts). In the public beta we will start off with shared hosting for sure, and if we grow at a greater rate than expected we will have a contingency plan of investing some money into a dedicated server. All this will be written up for our own use and getting it clear in our heads.

As (if?) the site grows we will certainly be looking towards investment, either through personal funds (if it's a small amount), bank loans, friends and family or private investors.

Thankfully my business partner is better with thinking about these and we compliment each other well, he's the backend man whilst I do the front-end, as well as other good traits.


All in all we realise this is a big project and one that could leave us out of pocket. We both believe there's a market and we will look into that further in the near future, so we'll give it our best shot. Thankfully with the way the web works we can start this off and gauge interest before having to splash large amounts of cash.