I am making a site where user can register and make posts using PHP.
Currently I have 2 tables in a db, and lots of csv files. Both of them together hold, username, password etc. and counters, posts, date etc respectively.
My Question is If it is a good idea to go with two storage systems. Of course i can store all of it in a database. My main concern is fast read & write capability.
Also note that some data is required frequently, and some is required rarely, if i have to divide the data b/w csv & db, what can be better way?
Use only DB, CSV is not for that.
Related
Well, Maybe 5M is not that much, but it needs to receive a XML based on the following schema
http://www.sat.gob.mx/sitio_internet/cfd/3/cfdv3.xsd
Therefore I need to save almost all the information per row. Now by law we are required to save the information for a very long time and eventually this database will be very very veeeeery big.
Maybe create a table every day? something like _invoices_16_07_2012.
Well, I'm lost..I have no idea how to do this, but I know is possible.
On top of that, I need to create a PDF and 2 more files based on each XML and keep them on HD.
And you should be able to retrieve your files quickly using a web site.
Thats a lot of data to put into one field in a single row (not sure if that was something you were thinking about doing).
Write a script to parse the xml object and save each value from the xml in a separate field or in a way that makes sense for you (so you'll have to create a table with all the appropriate fields). You should be able to input your data as one row per xml sheet.
You'll also want to shard your database and spread it across a cluster of servers on many tables. MySQL does support this but I've only boostrapped my own sharding mechanism before.
Do not create a table per XML sheet as that is overkill.
Now, why do you need mysql for this? Are you querying the data in the XML? If you're storing this data simply for archival purposes, you don't need mysql, but can instead compress the files into, say, a tarball and store them directly on disk. Your website can easily fetch the file in this way.
If you do need a big data store that can handle 5M transactions with as much data as you're saying, you might also want to look into something like Hadoop and store the data in a Distributed File System. If you want to more easily query your data, look into HBase which can run on top of Hadoop.
Hope this helps.
Is there any pro or con to have either for a website with few ammounts of user data stored? As of now, I have one database with all needed user data (addresses, telephone etc). Now I'm considering making a database to keep track of current events, of which some are linked to specific users. Other than perhaps making it more "tasteful" to separate data by "type" (a user database, and an "event database"), is there any real reason to do so? The amount of users will never go past 100.
If you're going to be linking user data and current event data, it will be significantly easier to have that data in separate tables in a single database.
If you actually mean having multiple databases for a small website, then no. You would want 1 database for the entire website, especially if it is small. You would want multiple tables though.
I am assuming you are getting a database and a table mixed up, which would then make your question make sense, and then yes, you would want multiple tables in your database to store different information.
It's always best to split things. Use one table for users, and another for the events. With a few users you won't have a problem if you use only one. But have it in mind for future references
I am doing a project (PHP) where i need to store about 4 different pieces of text about a person, each containing about 250 characters. there is currently no limit to the number times this must be done.
Would you suggest I store the 4 pieces of text in a database table and pull the text out of this, whenever a user enter the given persons page/profile, or should i rather make files out of them?
Which method would be the best in terms of speed, scalability etc.
Thanks
Databases are the perfect solution for what you want to do, and PHP has plenty of functions to work with them, so you don't have to reinvent the wheel to store data in flat files.
Think, for instance, of the pain you'll have in 6 months time when you'll have to take all those files and add a column to each one of them...
With a DB you'd just have to run one very simple query.
So, essentially, use a DB.
I would do this in a database. File operations are (as I recall) slower than doing a database query. The fact that you'll potentially have ~1k data for each person with a potentially unlimited amount of persons suggests that it would be better to do in a DB than as a text file. Define your table and then insert/select. The records are always gaurnteed to have consistent structure and you'll not have to worry about tripping over the delimiter character for fields.
So I have a simple Apache with MySql I am developing a PHP app. I have Users Table in my DB. I vant to let them store Icons.
My question Is what's the best way of attaching such data as icons (100-250kb's) to DB - Is it beter to store them Inside DB or store them as File and some how attaching links to icons into DB. What's the best way? Are there any classes that automate this process (of attaching such data to DB)?
I would store them as files, and reference them from the database. I made the mistake of storing images in the database itself (as BLOB I think) and regretted it the next day when db-connections had to stay opened longer, images didn't cache when I went to view them multiple times, etc.
I would only suggest storing the image itself in the database if it's absolutely necessary. If you're going to be using these images frequently, and showing them in multiple placed, I would suggest storing filepaths only in the database, and keeping the images in the filesystem.
Related: Storing Images in DB - Yea or Nay?
easier to keep the icon as a file and store the path in the db
the most efficient way to serve the image is by having the web server transmit a file directly from disk, so you may as well keep it there. having it in the db would make serving take longer and would have little purpose (there's no need to search through the binary data of the image and this would increase the size of each row in the db by a large amount, making read/iteration operations much less efficient because of the reduced locality)
I am planning to start a site in which the content is generated by the users. What is the best method to save the data submitted by user?
Is the method of saving the data in phpmyadmin database a good idea considering that the data submitted by users is large similar to a blog post. Btw I'm good in working with php and mysql but I'm not sure whether it is a good method.
By 'phpmyadmin' database I assume you just mean a MySQL database.
Since your user data is basically a 'blog post' - basic text and HTML, and you'll most likely be storing username, posting dates, titles, and the like as well -- a MySQL database is a fine place to store it.
If you're using standard shared hosting, your options are pretty much a relational database (MySQL) or a flat file. Between those two choices, a relational database is the better option.
Not sure just what you're asking here - If you're thinking of actually trying to save a .jpg file and text as blobs physically stored in the database, don't. Not if you intend to have a lot of users all uploading stuff. Look into saving it on your server in a folder for the user or better yet to the cloud - it'll be cheaper in the long run and save you tons of anguish with a corrupt database.