Jump to content

If you answer, you're PHP MASTER


TheFilmGod

Recommended Posts

I'm trying to build a mysql database that may have up to millions (in the far far future) number of tables upon tables. I want to make it efficient and work fast. How do I design a good mysql schema that will work effeciently, fast, and easy to maintain along side php? If  you know a link to a good tutorial please post!!

 

Thanks for help in advance! (The resources listed under php freaks about mysql organization is NO HELP).

Link to comment
Share on other sites

Thanks a lot. Its all starting to make sense.

 

I'd like to follow up with another question. Let's say I'm making a site like facebook. And there is information on each person. Is it the best idea to make a HUGE table with everbody's information. Or is it better to create a few tables, each with a cateogry. Like a table for general information and one for "favortie friends." Which solution is better? A huge table or a few tables, a table for a category?

 

Don't worry, I'm not actually going to create this! :D And mysql wouldn't be able to handle that much of an overload. I'm just giving an example.

Link to comment
Share on other sites

It depends on what the data looks like.  You would probably have a main table to include information that every user will have like name, login, password, location, sex, etc.

 

then for other dynamically sized datas such as number of friends, messages, bullitins, etc, you would probably use other tables.

 

does that make sense to anybody?

Link to comment
Share on other sites

A Table should contain all data that can have the same fields like users, or advertisments, logs, etc etc you shouldn't make a table for each user you should make a entry in the table users for each user.  Only way you need a bunch of tables is if some how each user had a way/need for a customized table

Link to comment
Share on other sites

millions of records??? use oracle

and to normalize ur table and save save space use id instead of usinf the whole word

 

say absent, late , ontime insread of using the whole word u can have just the id to serve as identifier.

  now look  late , ontime insread  this is lonfg enough to understand what i mean now if u use their id it will only look like this 1, 2, 3 see 3 characters are only store in your db

Link to comment
Share on other sites

i'm not claiming to be a php expert at all, but my understanding is that while mysql can hold large volumes of data it is not intended to have millions of entries.  A table can have lots of data (blob,text can hold flat files in binary).  But for million of entries its not meant for that because the primary use of mysql is a fetch method, not a echo out an entry.  More corperate style db like oracle would probably be best for your system.  You might be able to get away with flat filing and mysql if you have a powerful server and layout your organization in a good way.

Link to comment
Share on other sites

Normalization is the key.

 

You want your tables to be in 3NF form. MySQL will work just as well as Oracle if configured properly.

 

Basically here is how a design for let's say friends would work:

 

create table users( 
userid int(11) NOT NULL auto_increment,
username varchar(50) NOT NULL,
firstname varchar(30) NULL,
lastname varchar(50) NULL,
password varchar(50) NOT NULL,
email varchar(250) NOT NULL,
Primary key(userid)
);

Create table friends (
friendid int(11) NOT NULL auto_increment,
userid int(11) NOT NULL,
frienduserid int(11) NOT NULL,
active tinyint(1) NOT NULL default '1',
Primary Key (friendid)
);

 

That is an example of 3rd normal form. That is the best way to really structure tables in a sense. This is a zero to many relationship between friends and users.

 

There is no need for a ton of tables, just tables that are necessary, in this case friends table is necessary as there can be multiple friends for a user. But to store the users personal information in a seperate table would no be necessary as really you will only need one record per user.

 

And for thousands of records, MySQL works great. I have over 200,000 records in my database including templates, blogs comments, users etc. And my site runs just as smooth as it did with 1 record. The database is over 250MB's in size to give you an idea.  MySQL is very efficient.

Link to comment
Share on other sites

From memory MySQL can handle any size of database - its the table size that is important - 4G is (from what I remember) the point where things go boobies up.

 

Its the use of resources that are paramount.  provided you apply the normalization well then all should be dandy.  If you know your site WILL get bigger and bigger I'd go as far as to normalize the names of people!!!!

 

Although I have rarely used oracle I would concede it is much more robust and has some very useful functions that you can't directly replicate in mysql.  That said I believe MySQL is more than capable of providing the efficient resource 99.99999% of websites would ever need...

Link to comment
Share on other sites

So its better to have few tables that have a lot of records, then a lot of tables and a few records?

 

Yes.

No no.

it depends upon what type of data you are inserting into tables.

If you are doing something thats Pluggable You should use Separate Pluggable Tables.

Suppose You have a Shop That has a Main Brunch and many sub brunches.

You should make separate tables fro the Sub brunches. That are Connected by a Primary key like shop_id.

As you are handling 1000s of records you shouldnt have more than 8-10 Columns in 1 Table. If some Columns are interrelated make a separate table for them.

According to DBMS you should do this for Maximum performance.

Link to comment
Share on other sites

Wow. Thanks for everyone who replied. I see this came down to a very HEATED debate  :P.

 

Some keypoints I'd like to highlight: Better to make a table for each category. A table for general information, one for login, another for friends, etc. Another thing is to use id keys for repeated terms. So disk space is conserved. Lastly, NORMALISING the mysql.

 

I'm still a bit confused but it def. helped me a lot!!! :D

 

I'd like to follow up with a question. My host says my MYSQL limitation is:

 

We allow up to 50 simultaneous connections per MySQL user.

 

What do you think this means? I don't want to overload the MYSQL.

Link to comment
Share on other sites

so find allot of php master ?? funny great idea many answer the topic

 

LOL!  :D Its sorta like forum advertising! Why should someone reply to YOUR topic? Unless it makes them a php master!

 

Yeah, I found a lot of 'php masters'. Everyone pretty much. But there were some ppl I know were completely wrong...

 

Anyone know what 50 simultaneous connections per mysql user means?

Link to comment
Share on other sites

It means your only allowed to use 50 database's but within

all those 50 databases you can have many tables and colums/fields.

 

The new version off mysql outways many other databases.

I have used them all and still say mysql is the best.

Link to comment
Share on other sites

Thanks. But on the c-panel for my hosting package it says: 1 of 10 mysql database setup. 9 more still not setup.

 

Its all confusing me! ???

 

I was thinking that it means that at anytime, I can have 50 ppl on my website and they can connect to the mysql and query it without trouble. But if more ppl need to connect, than there would be a waiting time. - a  delay.

 

I guess my host does this so I upgrade. By upgrading I increase the '50' to '100' or more...

Link to comment
Share on other sites

It means that at any point in time you can have a maximum of 50 open connections to a database.

 

Usually 50 is plenty, most hosts default to 25 I think or less. Basically a connection opens when a page starts to load and closes after the page is done, so it is really only open for around .5 seconds or less depending on how efficient your site is.

 

50 will be good until you start to see a "Too Many Connection" problems, thats when you bump up to 100.

Link to comment
Share on other sites

Omg! Thanks soo much frost!! You are a life saver. I finally understand what it means! Even my support doesn't know.  :P

 

I'd like to follow up with a question.... Can mysql hold a good amount of requests at a time. I'm currently on a shared server. Will that create any problems for the mysql?

Link to comment
Share on other sites

Shared servers are risky to begin with. If you have the funds and the means a dedicated is the way to go (cheap cheap end $1200/year). I love my dedicated server as you have full control over the number of connections to mysql, you know how many domains are on there and they are only domains that you allow.

 

But yea you should be fine with shared hosting, but generally they are just less secure, although a lot cheaper.

Link to comment
Share on other sites

the way to avoid exceeding your maximum number of connections is to not use persistent connections. the OOP mysqli is fabulous and while creating a connection uses a lot of resources the new imporved mysqli effort is not bad at all...

 

Try to optimize your database by index all fields that you will search on... and keep it tidy!

 

Good luck and have fun dealing with the frustration that sest in sometimes when you are trying to do something great and it just won't bloody play ball (then you realise that you have a closing brace in the wrong place or something else fundamental).

Link to comment
Share on other sites

This thread is more than a year old. Please don't revive it unless you have something important to add.

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...

Important Information

We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.