I am planning on working on a personal project over the summer that I feel I might be able to complete now that I have the understanding of databases. I want to have a database that is able to be filtered down on say attributes an image has.
For example, we have a database of images of cars. I want to see only images for Chevy. So I click on the "Chevy" tab. I want to be able to query data for Chevy and show images for only chevy cars.
I can structure my database that if I'm on "Chevy" it goes to "chevy" table correct?
I am yet to work on a real world model, so completely new to me.
From what I have understood you can store images in database as "Blob", but it sounds like it might be more preferable to store these images in a host directory on my website server, and store the path to them instead.
I want to ultimately expand this out to an mobile app for Android and IoS, I dont imagine that would affect the decision to much. But is a plan I would like to try and incorporate also later down the road.
Currently I am going to try and do a website application, then I'll work on a mobile app afterwords.
Popular database's seem to be Mongo, any other recommended for a beginner programmer?
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 new in web developers world. I have created a website (www.formsify.in) on Wordpress all by learning on internet. I know the basics of coding and programming languages, etc. and the interest so I learn quickly. Now my objective is to let users search and download documents (.pdf). The way I dl it now is by uploading the documents in Media and use buttons to navigate to the page which displays documents in a tabular form.
Now, this works if the documents are less in numbers. But I know the number of documents will increase and it will be very difficult for me to deal with uploading them one by one and creating tables all the time. So I thought to create
(1). Database of documents
(2). Uploading interface
(3). User interface
I want suggestions whether I am thinking in the right direction or can there be a better way to accomplish this. And if this is a right way to do
What database shall I use keeping in mind that I the documents to be stored online so the database should be online.
How should I go about creating the uploading interface keeping in mind that I am not a code-geek.
How shall I be going to design the user interface.
I know these are very wide and open questions. Also because stalwarts here will give me a non-commercial, non-biased view. I just need directions. I was able to create a decent website (as per my standards) when I didn't know much the only thing drove me to do that was that I was hellbent. I will be thankful for any suggestions.
Thanks,
.farhan
So, basically, you should have 2 tables:
User
Upload
User hold an ID and whatever information you want to have on the user and the upload table holds a unique ID, a user ID (of the uploader) and a path to the document
This way, you can select the uploads (add filters if needed) and you can construct the tables and views using the database results
The uploading is a simple html form that will send the file to a php script that will upload the file to a folder (rename it as well) and insert the new path in the dB.
The user interface just needs to hold a bit of html, with a form element and an action to a php script to handle the upload.
You can find the upload script on w3schools, just add the mysql insert to the database.
I know this question was asked in various ways here, but none of the answer is conclusive.
I have a system which among other things updates a website gallery.
I can both "upload" the file to the website (and save a copy at the system - needed) or just save it in the DB and save the space (and another upload). If I go with the files I would need to "notify" the webpage of every change (picture delete, add or change) instead of just making the change in the DB.
So:
If we are talking about a standard website with a picture gallery, is it best to save the pictures as pictures or in the DB?
If the webpage is very visited or very large, does it makes any difference?
Is the difference that significant? Or just go with the convenient way?
Although I presented my case I would like also to have a "more in general" answer, what is the "good" approach when talking about saving files.
Thanks in advance for clarifying it,
Michel.
Only put structured data in a DB. Images are files and should be kept on a files system. The performance of the DB will degrade more and more as the number of pictures / users grows. Instead create an image object which you can use to track the image location and meta data.
I have had the same problem with you in a previous project of mine.
I decided to go with only storing the path of the image in my database (which is just a string) and save the image in the file system, not in the DB.
This is the best practice in many ways.
It keeps your DB small, getting a large amount of rows is faster and DB back ups are significantly smaller.
Just put the images in a file and save the path in the DB so you can retrieve it later.
One of my sites is a social networking site running on MySQL. I use postal code and country information to geolocate users using a webservice. This webservice also allows you to download all their many tables of information so that you can access it locally. My site has gotten big enough that I wish to do this now.
My question is, should I create a new database on my site for all of this postal code and country information and all its tables, or should I incorporate those tables into my existing database for my social networking site?
What are the pros/cons either way?
When you're talking about scaling and want to know about other databases like NOSQL, you might find this article interesting: http://highscalability.com/blog/2010/12/6/what-the-heck-are-you-actually-using-nosql-for.html
I'd vote in favor of a separate database if you planned to use the data as read-only and put a web service in front of it to access it. Users would search it based on a small handful of parameters (e.g. address info to get lat/lon data).
I'd say put it in the existing database if you planned to JOIN it with other information in your current schema.
it will live on the same disk probably.
so disk space is not an issue.
if you query the tables in a completely separate manner, then no impact on the existing site.
if you query things together, then easier when all in one database.
overall administration of one database vs 2 is easier.
i think it's a no brainer... they go in one db.
Currently I'm working with an in house white label cms that we resell to multiple clients and it all runs from the same box/db.
I'm just looking at converting this to have an ecommerce version that we'll run alongside it.
I'm wondering whether there will be an issue keeping all the products/categories/orders in one db or whether it would be advisory to separate each instance of the site into its own db for this.
These white label instances will only be sold to smaller companies that probably wont have masses of traffic/products and are looking for a simple ecommerce site. Anything larger will definitely get its own hosting and db.
But for smaller scale stuff do you think a single db will be ok?
#Tim: Aye I agree completely, however as I'm working from an existing codebase all of the site specific filtering code is built in. All I need to do is add a couple of fields to each table and the backend will already take care of all that filter for me.
Also the codebase I'm working from is set up with multiple access levels, user(public), userAdmin(customer) and admin(me), and is built in suck a way that I can generate a new site from the admin portal. I then just need to upload new templates/css/js/images and the whole new site is created.
So theoretically it may be more work to have to separate out the ecommerce databases than it would be to leave it in one.
Hence the question, if there is likely to be issues with having multiple sites in one DB I'll split it out, but if it's not going to make too much odds I'll leave it as is...
In fact I think I just answered my own question, I'll implement it into the existing codebase and set it up to run on one db, with the knowledge that i can always install the whole codebase on another box and run a single site on it if I need to :)
Thanks for the quick reply
Having everything piled into a single DB is going to complicate your code considerably. Instead of it being a configuration difference (which DB to connect to), you're going to be peppering your code with filters based on the current customer. I would vote for separate DBs in a heartbeat. Even if you wind up with excessive load from all the small DBs, it should be easy to add a new DB server and point new sites to the DB on the new server.
I can't see the complications this would create in your code being worth it in the long run.