I have setup my own server for a multiplayer pvp game 3 days ago, I am using a plugin that allows players to earn points in the server and stores everything in a MySQL database which I have full access to.
Yesterday I started working on a website for my server and I came up with an idea to make the points system more interesting for the players, I want to make a table on my website that extracts the top 10 players from my database and puts them into a HTML table.
I tried searching for this online, but found answers that only allowed me to extract all players or sort them by name etc, I just need the top 10 with the highest value in the column "points".
The database table name is "ranks" the column with the names is "lastDisplayName" and the column with points is called "points"
I would really appreciate it if someone could help me find a way to put this in a table that sais Rank, Name and points.
Sadly I can't upload the picture to show what my table would look like.
Try the query below
SELECT DISTINCT lastDisplayName FROM ranks ORDER BY `points` DESC LIMIT 10;
Related
I am doing my master thesis and I found unknown problem.
I make football simulator app
-> you can simulate alternative football future for all European leagues.
But I have a problem in MySQL database
-> at the beginning of game I need to give user whole data.
But after this, some data evolves (some players score goals, teams have points), but I need to store these data for each user separately (for example, some user have 2 seasons simulated and some 10 seasons -> both with completely different results).
Is there any more effective way than having separate tables for each user (because for example players table have more than 50,000 rows)?
Thanks!
Using PHP7,node.js backend,MySQL db.
you can have one table for all users. Just seperate each user by user_id column.
create table seasion_with_users
(
session_id
user_id int,
....
....
);
also If you have storage concern, I suggest you to mutate only changing rows.
I've been trying to get this SQL query running for a while now and can't seem to get the last little bit going.
The backend database to all this data is a Drupal install with data spread out across a number of modules, so I need to do a lot of joining to get a certain view table set up that I need for a third-party application.
It's hard to explain the entire schema, but here's the sqlfiddle:
http://sqlfiddle.com/#!2/68df0/2/0
So basically, I have a userid which I map to a profile id through a join. Then I need to use that profile ID to pull the related data about that profile from two other tables. (there should only be one row with each pid in each of the other tables)
So in the end, I would like to see a table with username, othername, and key_id.
I got the first two pieces in there, but just can't seem to figure out how to join in the othername, and keep getting null.
The server is running MySQL.
Thanks guys!
LEFT JOIN other_name
ON profile_link.pid=other_name.pid;
I ask a similar question (1 table 150,000,000,000 rows) now I will add some details.
500,000 Items
Unlimited # Categories
15 Sections
The site allows users to create their own categories and place as many items into that category. Before they can add anything they must choose what section the category is best represented.
Each of the above will have: id, title, description, imageURL
I have two issues:
Each CATEGORY/ITEM will beable to re-arrange items/categories greatest to worst. COLUMN: rank
Users will be acknowledged for contributing most to category. COLUMN: king
This feature of the site is pretty simple but the ranking process is throwing me for a loop. I have tried multiple test runs cramming as much data into one table as possible but the results are crashing my spirits. The division of data to tables is not easy because of the individual ranking for each category.
The original design was to Have the above 3 and individual tables of each category/item to allow individual ranking(boost speed/performance) then:
User contributor: sectionID, categoryID, itemID, userID
Individual Rank: categoryID/itemID, rank
The outcome would be 150,000,000,000 tabled labyrinth. Has anyone dealt with this concept before? What is the best plan of action? Am I on the right track?
I just got High Performance MySQL, 3rd Edition
Optimization, Backups, and Replication and Beginning PHP and MySQL: From Novice to Professional 4th (fourth) EditionI am not promoting or endorsing these books...
These are the first of many steps I will be taking to tackle this design problem I face. Any comments and assistance will be appreciated. Thoughts; Concerns??
So I have this application that I'm drawing up and I start to think about my users. Well, My initial thought was to create a table for each group type. I've been thinking this over though and I'm not sure that this is the best way.
Example:
// Users
Users [id, name, email, age, etc]
// User Groups
Player [id, years playing, etc]
Ref [id, certified, etc]
Manufacturer Rep [id, years employed, etc]
So everyone would be making an account, but each user would have a different group. They can also be in multiple different groups. Each group has it's own list of different columns. So what is the best way to do this? Lets say I have 5 groups. Do I need 8 tables + a relational table connecting each one to the user table?
I just want to be sure that this is the best way to organize it before I build it.
Edit:
A player would have columns regarding the gear that they use to play, the teams they've played with, events they've gone to.
A ref would have info regarding the certifications they have and the events they've reffed.
Manufacturer reps would have info regarding their position within the company they rep.
A parent would have information regarding how long they've been involved with the sport, perhaps relations with the users they are parent of.
Just as an example.
Edit 2:
**Player Table
id
user id
started date
stopped date
rank
**Ref Table
id
user id
started date
stopped date
is certified
certified by
verified
**Photographer / Videographer / News Reporter Table
id
user id
started date
stopped date
worked under name
website / channel link
about
verified
**Tournament / Big Game Rep Table
id
user id
started date
stopped date
position
tourney id
verified
**Store / Field / Manufacturer Rep Table
id
user id
started date
stopped date
position
store / field / man. id
verified
This is what I planned out so far. I'm still new to this so I could be doing it completely wrong. And it's only five groups. It was more until I condensed it some.
Although I find it weird having so many entities which are different from each other, but I will ignore this and get to the question.
It depends on the group criteria you need, in the case you described where each group has its own columns and information I guess your design is a good one, especially if you need the information in a readable form in the database. If you need all groups in a single table you will have to save the group relevant information in a kind of object, either a blob, XML string or any other form, but then you will lose the ability to filter on these criteria using the database.
In a relational Database I would do it using the design you described.
The design of your tables greatly depends on the requirements of your software.
E.g. your description of users led me in a wrong direction, I was at first thinking about a "normal" user of a software. Basically name, login-information and stuff like that. This I would never split over different tables as it really makes tasks like login, session handling, ... really complicated.
Another point which surprised me, was that you want to store the equipment in columns of those user's tables. Usually the relationship between a person and his equipment is not 1 to 1 and in most cases the amount of different equipment varies. Thus you usually have a relationship between users and their equipment (1:n). Thus you would design an equipment table and there refer to the owner's user id.
But after you have an idea of which data you have in your application and which relationships exist between your data, the design of the tables and so on is rather straitforward.
The good news is, that your data model and database design will develop over time. Try to start with a basic model, covering the majority of your use cases. Then slowly add more use cases / aspects.
As long as you are in the stage of planning and early implementation phasis, it is rather easy to change your database design.
I need opinions on the best way to go about creating a table or collection of tables to handle this unique problem. Basically, I'm designing this site with business profiles. The profile table contains all your usual things such as name, uniqueID, address, ect. Now, the whole idea of the site is that it's going to be collecting a small string of informative text. I want to allow the clients to be able to store one per date, with as many as 30 days in advance. The program is only going to show the information from the current date on forward, with expired dates not being shown.
The only way I can really see this being done is a table consisting of the uniqueID, date, and the informative block of text, but this creates pretty extensive queries. Eventually this table is going to be at least 20 times larger than the table of businesses in the first place as these businesses are going to be able to post up to 30 items in this table using their uniqueID.
Now, imagine the search page brings up a list of businesses in the area, it's then got to query the new table for all of those ids to get that block of information I want to show based on the date. I'm pretty sure it would be a rather intensive couple of queries just to show a rather simple block of text, but I imagine this is how status updates work for social networking sites in general? Does facebook store updates in a table of updates tied to a users ID number or have they come up with a better way?
I'm just trying to gain a little more insight into DB design, so throw out any ideas you might have.
The only way I can really see this being done is a table consisting of the uniqueID, date, and the informative block of text...
Assuming you mean the profile uniqueID, and not a unique ID for the text table, you're correct.
As pascal said in his comment, you'd need a primary index on uniqueID and date. A person could only enter one row of text for a given date.
If you want to retrieve the next text row for a person, your SQL query would have the following clauses:
WHERE UNIQUE_ID = PROFILE.UNIQUE_ID
AND DATE >= CURRENT_DATE
LIMIT 1
Since you have an index on uniqueID and date, this should be a fast query.
If you want to retrieve the next 5 texts for a particular person, you'd just have to make one change:
WHERE UNIQUE_ID = PROFILE.UNIQUE_ID
AND DATE >= CURRENT_DATE
LIMIT 5