I'm creating a small community using the Symfony2 Framework and backboneJS.
When I took a look at the database today I realized that it might be wrong to store all images using this schema.
ImageTable
Id
Title
Owner
Description
Url
So when a user logs in and wants to have a look at his own images, I just loop through all images where owner == currentuser.
Is this a bad practice?
The more owners I have the longer the query its going to take, right?
I'm asking since it might take a week to restructure the whole website database and I don't want to fix what might not be broken.
I know a solution might be to set a manytomany relationship between the current user table and an own image table, but is it worth the effort?
As far as I can see, this is as normalized as it gets for your scenario. A many to many relationship is not what you are looking for, since a user may have multiple images, but an image can't have multiple owners (or can they?).
So if the Owner is a foreign key for the table user you are good.
Related
I'm working on a project to make a digital form of this paper
this paper (can't post image)
and the data will displayed on a Web in a simple table view. There will be NO altering, deleting, updating. It's just displaying (via SELECT * of course) the data inputted.
The data will be inserted via android app and stored in a single table which has 30 columns in mysql.
and the question is, is it a good idea if i use a single table? because i think there will be no complex operation in the sql.
and the other question is, am i violating some rules for this method?
I need your opinion. thanks.
It's totally ok to use only one table, if that suits your needs. What you can do to make the database a little bit 'smarter' is add new tables for attributes in your paper that will be repeated. So, for example, the Soil Type could be another table where there are two columns, ID and Description, and you will use it as a foreign key in each record in the main table. You need this if you want your database to be in 3NF.
To sum up, yes you can have one table if that's all you need. However, adding more tables might help save some space and make your database more flexible. It's up to you to decide! :)
I'm new to web design and I am making a niche social media site. I just want some general advice on the best way to design SQL database. I am using my sql and currently plan on having a profile table, that stores basic profile information (username, password, random other facts like location).
My question is can a cell serve as it's own separate table? I'm imagine each profile row will have a friends table inside of it that list all of the friends for that profile.
Is this the right way to go about designing? While not likely, i'd like a design good enough to scale in case I get thousands of users. Any advice would be greatly appreciated.
My question is can a cell serve as it's own separate table?
By "cell" I assume you mean a single value in a row. You cannot nest another table inside a row value. You could do something similar using an XML value, but more than likely what you are trying to accomplish is easily done using a foreign key in the friends table which references the primary key of the parent profile row. This known as normalization.
As for your other questions, those are too broad to be appropriate here. You should read through a basic tutorial/primer on database design. There are mountains of content someone could fill an answer with just to cover the basics of database design. "Database Normalization" and "database design best practices" are good starting Googles.
currently Im working on a project that, at first glance, will require many tables in a database. Most of the tables are fairly straightforward however I do have an issue. One of the tables will be a list of members for the website, things like username, password, contact info, bio, education, etc will be included. This is a simple design, however, there is also a need for each member to have their availability entered and store in the database as well. Availability is defined as a date and time range. Like available on 4/5/2011 from 1pm to 6pm EST, or NOT available every friday after 8pm EST. For a single user, this could be a table on its own, but for many users, Im not sure how to go about organizing the data in a manageable fashion. First thought would be to have code to create a table for each user, but that could mean alot of tables in the database in addition to the few I have for other site functions. Logically i could use the username appended to Avail_ or something for the table name ie: Avail_UserBob and then query that as needed. But im curious if anyone can think of a better option than having the potential of hundreds of tables in a single database.
edit
So general agreement would be to have a table for members, unique key being ID for instance. Then have a second table for availability (date, start time, end time, boolean for available or not, and id of member this applies to). Django might sound nice and work well, but i dont have the time to spend learning another framework while working on this project. The 2 table method seems plausable but Im worried about the extra coding required for features that will utilize the availability times to A) build a calender like page to add, edit, or remove entered values, and B) match availabilities with entries from another table that lists games. While I might have more coding, I can live with that as long as the database is sound, functional, and not so messy. Thanks for the input guys.
Not to sound like a troll, but you should take a look into using a web framework to build most of this for you. I'd suggest taking a look at Django. With it you can define the type of fields you wish to store (and how they relate) and Django builds all the SQL statements to make it so. You get a nice admin interface for free so staff can login and add/edit/etc.
You also don't have to worry about building the login/auth/change password, etc. forms. all that session stuff is taken care of by Django. You get to focus on what makes your project/app unique.
And it allow you to build your project really, really fast.
djangoproject.org
I don't have any other framework suggestions that meet your needs. I do... but I think Django will fit the bill.
Create a table to store users. Use its primary key as foreign key in other tables.
The databases are written to hold many many rows in a table. There are not optimized for table creation. So it is not a good idea to create a new table for each user. Instead give each user an unique identifier and put the availability in a separate table. Provide an additional flag to make an entry valid or invalid.
Create a table of users; then create a table of availabilities per user. Don't try to cram availabilities into the user table: that will guarantee giant grief for you later on; and you'll find you have to create an availabilities table then.
Google database normalization to get an idea why.
Take it as truth from one who has suffered such self-inflicted grief :-)
This isn't much of a coding question as opposed to seeking help on going down the right path. So, I have my users set up with username, password, email, posts, & id. The basic forum stuff. But, if I were to add more, say some games in the website that you play and store data with your forum account (being your account for the whole website, in other words), would it be wiser to add those fields to the existing table (i.e.: game1_money) or make another table for each individual side project, then create and link it to each user upon starting the "game" or whatever it is?
If I'm too vague, tell me and I'll try to clarify.
Use separate tables and then a left join when you want the data for the specific game or application. Then if 10% of the users are signed up for the game you don't waste the table space for the other 90%. You also don't need to keep fiddling with the user table.
Anonymous,
Always try to keep your primary table clean and relate everything back to a unique, individual index. In this case, whether you add games, comments, documents, whatever...user User_ID (for example) as the related index field that points back to your main users table.
Here's a good reference on building normalized tables
http://dev.mysql.com/tech-resources/articles/intro-to-normalization.html
Don't store that information in the Users table. Normalise into separate tables.
Create a separate table, say GameSavedInfo, to store this information and reference the users ID from the user table.
I would also create a GameDetails table and use its Id in the GameSavedInfo table.
I'm about to implement a list of topic/argument in my forum, and I'd like to insert a sort of flag like "read/not read yet" for each message, regard each user in my website.
I think at somethings like this : a table watched_topics with id(INT), user(VARCHAR) and topic_id(INT). When a user watch the page, I'll insert (if the data doesn't exist) these information.
When another user will insert a new message in a topic, I'll delete from the table watched_topics all line with that topic_id.
That could provide a trouble : Think about to 9000 topics and 9000 users that have watched all topics : the table will be so big (9000x9000=81000000).
So, I think is not the best strategy to implement this kind of stuff! Any suggestion would be appreciated :)
Cheers
May I suggest a different approach?
Make use of web browser history mechanism.
Every topic can get a new, unique URL every time a new message is added there. It could include the number of messages, last modified time or a combination of both.
If the user did see the topic, he must have visited it, so a properly set up CSS can help identifying the read ones. You can even use some client-side scripts to modify the behaviour of the page based on that.
Another way to do that would be to keep the watched topics table the way you want to do it, but also store last visit time in user's profile and show all topics as read that haven't changed since that time.
However it's pretty safe to assume that all users reading all topics is very unlikely.
Your suggestion sounds good. I would make user-field also a foreign key - it gives you a bit more flexibility.
Are you sure all 9000 topics are read by all 9000 users? I mean is this reality? Like you said, topic-entries are deleted when new message is added. And when that happens, another 9000 entries are deleted :)
I would index the table and go with your suggestion (with user_id change). If the table size gets in your way, you can always change the implementation later. Most likely it will never be the issue anyway.
For the deletion: you could save what the latest msg-ID was the user saw. This way you do not have to perform a lot of delete actions every time a msg is posted in a much-viewed topic.