Hey there…
Im trying to make an online saving system through a database server.
What type of solutions is best?
MySQL? MS? one row per player or one table per player?
There is alot of information needed to be stored i various category, thats why one table per player sounds easier to keep in order, but I dont know if its too much info?
How many “Save profiles” can one single server handle with fair amount of hardware (quad core, 8 gigs ram, 3 ghz etc, 100 mbit/s)
Hope someone of you have any suggestion or even experience in this subject 
There are many, many factors.
For example, I would have a table of basic account information (login, password, e-mail, etc). If the game had quests/achievements, that would be another table. Inventory items or equipped items, would be another table. Character stats would be another table.
No single table would be too big that it would be laggy trying to search through. Again, this depends greatly on the type of game you’re making. What exactly you’re trying to save, and possibly the genre as well.
I prefer mySQL, but that’s a bit biased. I would imagine in your case, just as a general “blanket” solution, to have a character table, with one row per character. If you could provide me with a bit more general information about your game (what would you like to save, etc), I could come up with a better answer.
I would make a login server as you also say, with login, password, name, email and ID.
I havent thought about a table per category though. maybe this aproach would work.
Things needed to be saved is Position (wich might be a server by it self cuz of alot of request and data change).
The game is RPG style so things like, inventory(50+ items + amount of item) quest information etc. in character information.
Also 1000+ items, 250+ quest and all those things. all in all alot of info.
Unless your data record is enormous, you aren’t likely to run into any hard limit for the amount of data you can store. I would expect one record per player to be much more practical than one table per player. However, you can often get better performance from a DB by dividing a large record into two or more smaller records according to what they call “hot” and “cold” fields. Basically, hot fields are the pieces of data accessed most regularly and cold fields are things that are needed only occasionally. Having all the data in one big record means that cold data is pulled along with hot data during each request, even when it isn’t needed. This makes poor use of the DB’s memory cache; having separate hot and cold tables makes for better cache usage and will generally give you a bit of a speed boost.
Okay thanks alot, this helped me out big time