I'm writing an online project asset tracker but I'm new to MySQL. What would be the best way of tracking projects, users, and assets for something like this? I have 3 tables for assets, users, and projects. Users should own projects and assets. Assets could be members of multiple projects, and projects should be able to be seen by multiple users.
The first method I figured would be to have a mediumtext field on each project with the id for every asset that it's linked to. Each asset would also have a mediumtext that will have every project id it's linked to. This is a problem though, since I can't really do a search without having to parse the text to find out the projects/assets it's attached to.
Another solution without parsing would be to have separate tables for the linking information, so for instance there would be an asset table with the asset id, project id, and userid that it's part of, and if it gets assigned to another project or user, there would be another entry into that table. This solution, though, will have assets that have multiple entries.
Another way of doing it would be to have the site create a table whenever a project is created, and that will store the asset and user information. Since there might be thousands of projects, this will crowd up the database pretty quickly, and creating tables is heavier on MySQL than entries, as far as I know.
I'm leaning toward the second solution. Is there anybody who knows a better way?
Quote:
have a mediumtext field on each
project with the id for every asset
that it's linked to
This is the worst design... maybe ever! Read up on database relations. Take an emergency crash course. Look at some example databases; MS Access has some pretty decent templates you could examine.
What you describe looks like it could be modelled with these relations:
project --- inf:inf --- users
asset --- 1:1 --- users
asset --- inf:inf --- projects
The many-to-many relations would go in a separate table.
Related
I am creating a CV website, but in difference to most I am trying to make it with database. I mean that usually such websites are static and all of the information is hard coded in the HTML. Since I am back-end developer I like to make it so everything including buttons and welcome messages are taken from the database. I am trying to store projects that I have worked on. There are several types:
Github Repository - a project that is done purely on github.
Work related - a project I have done on work and there is no github repository of it, only link to view the final result
UpWork or other freelance website - as a freelancer I have projects to fix something on a website and those projects can be viewed only on my profile there and I would like to list them with link to UpWork or wherever there is information on what exactly I was hired to do.
Now my question is - should I have different Entities and therefore different tables for these types of projects or should I have all of the possible properties in one table. For example if it is Github there is repository field and if it is work related then there is company field. If it is freelance it has link to the website I was hired on. Also there are different sub-types - web applications, desktop applications, games and so on.
As you can guess the changes are small (1 or 2 properties). I could very easily leave empty some properties and have another property projectType, but is this the right way? Should I have different tables and entities for them?
To give some info - I can work with both MySQL and NoSQL and I havent decided yet on which one should my website be made on. I am currently thinking about NoSQL. This means I am asking on how to store the projects on MySQL and NoSQL (by NoSQL I mean MongoDB). If it helps the languages I am choosing from are PHP (MySQL) and JavaScript (NoSQL)
I know that usually questions without code are downvoted, but this is more of a logic based problem as I know how to do it, but I don't know the best practices for my situation. This being said here is a small code for you -
console.log('Thank you in advance')
MongoDB lends itself very well to this exact situation.
You can create a collection where documents leave out certain fields if they are not needed for that type. The querying parameters of MongoDB allow you to check $exists on fields if you need to, and documents are stored efficiently, only taking up memory where a field is needed.
You can even setup a sparse index which is not required for every document. As long as your core document structure is the same, it is a good idea to keep them in one collection, and vary them based on their type.
I am developing a site which will contain user projects, basically a bunch of user data:
- Projects
- Templates
- Invoices
- etc
Users can have multiple projects etc.
I would like to know the best route to contain this data, I originally though of having the user_id and project_id in the tables e.g:
Projects:
User Id,
Project Id,
..,
..,
Project Settings:
User Id,
Project Id,
Settings Id,
...,
...,
I am thinking that this may not be the best way to do this for security, performance and scalability.
I am happy keeping the Wordpress main database as MySQL and was thinking of maybe an object database for the user project data.
The wp database abstraction is essentially non-swappable and the API consists of random global functions. If you plan on using wp for the presentation layer in your project my advice is to build the back-end for your data completely decoupled from wpdb.
Look for pdo and sqlite integrations in the public plugin repo. Notice how the entry point is implemented. If that does not scare you, have a look at the usermeta functions.
i'm starting a project about a social-based application, so i need to track users actions in time. To avoid an Epic-Sized table, i'm thinking about create a table for every single user, and record actions by user.
I've never heard about links of this type (row to table) and i don't know where to find some documentation about this particular argument.
About this, my boss wants to use Drupal for this project, someone have infos about this kind of structure in particular in drupal?
Hmm...maybe you should go for some "lower level" solution instead of Drupal. Drupal is CMS and if you make website Drupal's way you won't have freedom defining your tables the way you like. It's more you have one table defining some common (default) content type fields and for any new you add Drupal actually creates new table so you end up with some complex database structure.
Of course you can manually create your tables and use them also manually instead of using drupal's nodes and views and stuff, but then...what's the point of using Drupal?
So, IMHO some framework or even plain PHP would be more suitable for your project.
I have several different web applications with their own separate databases. All of these different web applications also use a common database for authentication which contains the list of all of my users and the user's name. To keep things simple, let just say my application databases are like a forum and they track user posts; in the tables they will store a userID and some post text.
Now the problem I am having is that some of my team members feel that what we are doing is messy and frictional because it kind of a pain how to get my applications to display a users name next to their posts which is a very common task. First I have to go to the application database and do something like SELECT userID, postText FROM tblPosts then I have to take that userID and go to the user database and get the actual name with SELECT name FROM tblUsers WHERE userID = X. And then merge data from those two queries together to get it out on the page.
I personally don't mind the way we are doing it as I think it's important to just use a single separate user database for data constancy, but some of my team members want to copy over all of the user names into the local application databases and store the user name next to the userID when recording posts so its super simple to get that information back out. In the event a user wants to change their name (a very infrequent event and we only have about 100 users) we should just run an update in the common database as well as all of the application databases.
This seems like a common issue people might have. Can someone please weigh in on the common approaches to dealing with the problem and what we might want to do.
You have a system with a working single-signon scheme (centralized user identity and authentication). That's a huge competitive advantage.
You've built it simply and cleanly. That's even more huge. This kind of thing is very hard to get right, and you have done that.
(If you were to try to build this with some system like LDAP or Active Directory, you'd have a lot of complex code to maintain.)
Don't let your fellow developers sacrifice that advantage for their personal convenience. If you have to synchronize changes to the user database, you will have problems when things get out of sync. It's a when question, not an if question.
By the way, if your user database and website specific databases are on the same MySQL server, you can do stuff like this to integrate the use of the two different databases. That may meet the needs of your developers.
SELECT u.username, d.opname
FROM userdatabase.users u
JOIN website.transaction d ON u.userid = d.userid
But if you do this, you'll make it hard to migrate your various website databases to other server machines in the future.
I am making a semi-simple web application for my mother using php, mysql, and javascript.
She is a teacher, and this wil allow her to manage various components of her lesson plans.
For each component there is a table, and for each component that can contain another component there is another table that holds the relationship. (That table type has two columns each has a foreign key to the related tables)
I am nearly done, but she now wants to allow her friends to use this, I don't care too much about sql injection, but I would like to implement User Control so that only users that create a component can view and edit that component.
I also want them to be able to make public components, so that users can copy components to their own dataset.
My question To implement the user control should I have each user have there own database instant, or should each table have an owner column and column for public/private status, or is there another alternative that I have not thought of.
An issue that I see is that it would require additional mysql query when creating the relations between components because I would need to check that both components user tag matches the current user.
Any feedback/suggestions are helpful
Update The only people using/accessing this will be other teachers, that will be developing their own lesson plans
I would certainly implement this within the same database. Having a different database for each user is not a good solution in this case. Think, for example, how you would build a search function if each user's data is in a separate database will clashing UIDs. It would be a nightmare. Separate databases work where each database serves a separate application and there are precisely zero relations between the data in different databases.
So that brings you on to how to implement it. This will depend on your model. Will each lesson plan only ever have, for example, one and only one owner? If so, then adding that info to the components table might work. Or else you might need a separate table to define ownership and hence access to the different components. Either way, I would make sure the access logic is decoupled and encapsulated in your application to make sure you can change it in the future. Imagine for example you start with a simple, single-owner model but the site grows and grows and soon groups of people all need ownership/edit access to components.