Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.databases.mysql > #596 > unrolled thread
| Started by | "Robert Crandal" <rcranz143101@gmail.com> |
|---|---|
| First post | 2011-04-23 23:47 -0700 |
| Last post | 2011-04-25 16:46 +0200 |
| Articles | 20 on this page of 103 — 13 participants |
Back to article view | Back to comp.databases.mysql
Can MySql database store images? "Robert Crandal" <rcranz143101@gmail.com> - 2011-04-23 23:47 -0700
Re: Can MySql database store images? "J.O. Aho" <user@example.net> - 2011-04-24 09:23 +0200
Re: Can MySql database store images? "Robert Crandal" <rcranz143101@gmail.com> - 2011-04-24 01:19 -0700
Re: Can MySql database store images? "J.O. Aho" <user@example.net> - 2011-04-24 11:13 +0200
Re: Can MySql database store images? The Natural Philosopher <tnp@invalid.invalid> - 2011-04-24 11:17 +0100
Re: Can MySql database store images? Tim Watts <tw@dionic.net> - 2011-04-24 13:06 +0100
Re: Can MySql database store images? Jerry Stuckle <jstucklex@attglobal.net> - 2011-04-24 08:42 -0400
Re: Can MySql database store images? Tim Watts <tw@dionic.net> - 2011-04-24 14:45 +0100
Re: Can MySql database store images? Jerry Stuckle <jstucklex@attglobal.net> - 2011-04-24 10:27 -0400
Re: Can MySql database store images? Tim Watts <tw@dionic.net> - 2011-04-24 19:04 +0100
Re: Can MySql database store images? Jerry Stuckle <jstucklex@attglobal.net> - 2011-04-24 14:44 -0400
Re: Can MySql database store images? Tim Watts <tw@dionic.net> - 2011-04-24 20:51 +0100
Re: Can MySql database store images? Jerry Stuckle <jstucklex@attglobal.net> - 2011-04-24 17:03 -0400
Re: Can MySql database store images? Hans Castorp <REWYRLXHEGHO@spammotel.com> - 2011-04-24 23:18 +0200
Re: Can MySql database store images? Jerry Stuckle <jstucklex@attglobal.net> - 2011-04-24 19:55 -0400
Re: Can MySql database store images? Tim Watts <tw@dionic.net> - 2011-04-25 08:30 +0100
Re: Can MySql database store images? Jerry Stuckle <jstucklex@attglobal.net> - 2011-04-25 06:32 -0400
Re: Can MySql database store images? Tim Watts <tw@dionic.net> - 2011-04-25 12:04 +0100
Re: Can MySql database store images? Jerry Stuckle <jstucklex@attglobal.net> - 2011-04-25 07:18 -0400
Re: Can MySql database store images? Tim Watts <tw@dionic.net> - 2011-04-25 13:32 +0100
Re: Can MySql database store images? Jerry Stuckle <jstucklex@attglobal.net> - 2011-04-25 09:09 -0400
Re: Can MySql database store images? Tim Watts <tw@dionic.net> - 2011-04-25 14:17 +0100
Re: Can MySql database store images? Jerry Stuckle <jstucklex@attglobal.net> - 2011-04-25 19:29 -0400
Re: Can MySql database store images? The Natural Philosopher <tnp@invalid.invalid> - 2011-04-25 12:30 +0100
Re: Can MySql database store images? Tim Watts <tw@dionic.net> - 2011-04-25 13:59 +0100
Re: Can MySql database store images? The Natural Philosopher <tnp@invalid.invalid> - 2011-04-25 18:10 +0100
Re: Can MySql database store images? Norman Peelman <npeelman@cfl.rr.com> - 2011-04-24 16:40 -0400
Re: Can MySql database store images? Jerry Stuckle <jstucklex@attglobal.net> - 2011-04-24 17:05 -0400
Re: Can MySql database store images? Norman Peelman <npeelman@cfl.rr.com> - 2011-04-25 02:57 -0400
Re: Can MySql database store images? Tim Watts <tw@dionic.net> - 2011-04-25 08:59 +0100
Re: Can MySql database store images? Norman Peelman <npeelman@cfl.rr.com> - 2011-04-25 21:41 -0400
Re: Can MySql database store images? Norman Peelman <npeelman@cfl.rr.com> - 2011-04-26 06:20 -0400
Re: Can MySql database store images? dougatmilmacdotcom@example.com (Doug Miller) - 2011-04-26 14:10 +0000
Re: Can MySql database store images? Norman Peelman <npeelman@cfl.rr.com> - 2011-04-26 22:24 -0400
Re: Can MySql database store images? The Natural Philosopher <tnp@invalid.invalid> - 2011-04-27 08:24 +0100
Re: Can MySql database store images? Norman Peelman <npeelman@cfl.rr.com> - 2011-04-27 06:41 -0400
Re: Can MySql database store images? Tim Watts <tw@dionic.net> - 2011-04-27 12:32 +0100
Re: Can MySql database store images? The Natural Philosopher <tnp@invalid.invalid> - 2011-04-27 15:07 +0100
Re: Can MySql database store images? "Peter H. Coffin" <hellsop@ninehells.com> - 2011-04-27 07:11 -0500
Re: Can MySql database store images? Tim Watts <tw@dionic.net> - 2011-04-27 13:34 +0100
Re: Can MySql database store images? "Peter H. Coffin" <hellsop@ninehells.com> - 2011-04-27 09:25 -0500
Re: Can MySql database store images? Tim Watts <tw@dionic.net> - 2011-04-27 16:32 +0100
Re: Can MySql database store images? Jerry Stuckle <jstucklex@attglobal.net> - 2011-04-24 10:28 -0400
Re: Can MySql database store images? Norman Peelman <npeelman@cfl.rr.com> - 2011-04-24 16:43 -0400
Re: Can MySql database store images? Tim Watts <tw@dionic.net> - 2011-04-25 08:36 +0100
Re: Can MySql database store images? Jerry Stuckle <jstucklex@attglobal.net> - 2011-04-25 06:34 -0400
Re: Can MySql database store images? Tim Watts <tw@dionic.net> - 2011-04-25 11:50 +0100
Re: Can MySql database store images? Jerry Stuckle <jstucklex@attglobal.net> - 2011-04-25 07:20 -0400
Re: Can MySql database store images? The Natural Philosopher <tnp@invalid.invalid> - 2011-04-25 12:42 +0100
Re: Can MySql database store images? Luuk <Luuk@invalid.lan> - 2011-04-24 16:27 +0200
Re: Can MySql database store images? The Natural Philosopher <tnp@invalid.invalid> - 2011-04-24 15:38 +0100
Re: Can MySql database store images? Luuk <Luuk@invalid.lan> - 2011-04-24 16:41 +0200
Re: Can MySql database store images? Tim Watts <tw@dionic.net> - 2011-04-24 19:07 +0100
Re: Can MySql database store images? Jerry Stuckle <jstucklex@attglobal.net> - 2011-04-24 14:46 -0400
Re: Can MySql database store images? Tim Watts <tw@dionic.net> - 2011-04-24 21:01 +0100
Re: Can MySql database store images? Jerry Stuckle <jstucklex@attglobal.net> - 2011-04-24 17:10 -0400
Re: Can MySql database store images? Tim Watts <tw@dionic.net> - 2011-04-25 08:23 +0100
Re: Can MySql database store images? Jerry Stuckle <jstucklex@attglobal.net> - 2011-04-25 06:39 -0400
Re: Can MySql database store images? Tim Watts <tw@dionic.net> - 2011-04-25 12:00 +0100
Re: Can MySql database store images? Jerry Stuckle <jstucklex@attglobal.net> - 2011-04-25 07:27 -0400
Re: Can MySql database store images? Tim Watts <tw@dionic.net> - 2011-04-25 13:42 +0100
Re: Can MySql database store images? Jerry Stuckle <jstucklex@attglobal.net> - 2011-04-25 09:12 -0400
Re: Can MySql database store images? Tim Watts <tw@dionic.net> - 2011-04-25 14:23 +0100
Re: Can MySql database store images? Jerry Stuckle <jstucklex@attglobal.net> - 2011-04-25 19:31 -0400
Re: Can MySql database store images? "Mr. B-o-B" <mr.chew.baka@gmail.com> - 2011-04-25 20:30 -0500
Re: Can MySql database store images? The Natural Philosopher <tnp@invalid.invalid> - 2011-04-25 12:21 +0100
Re: Can MySql database store images? Tim Watts <tw@dionic.net> - 2011-04-25 13:46 +0100
Re: Can MySql database store images? Jerry Stuckle <jstucklex@attglobal.net> - 2011-04-24 13:23 -0400
Re: Can MySql database store images? Luuk <Luuk@invalid.lan> - 2011-04-24 20:31 +0200
Re: Can MySql database store images? Jerry Stuckle <jstucklex@attglobal.net> - 2011-04-24 14:48 -0400
Re: Can MySql database store images? Luuk <Luuk@invalid.lan> - 2011-04-24 21:11 +0200
Re: Can MySql database store images? Axel Schwenke <axel.schwenke@gmx.de> - 2011-04-24 21:24 +0200
Re: Can MySql database store images? Jerry Stuckle <jstucklex@attglobal.net> - 2011-04-24 17:34 -0400
Re: Can MySql database store images? Luuk <Luuk@invalid.lan> - 2011-04-25 12:04 +0200
Re: Can MySql database store images? Jerry Stuckle <jstucklex@attglobal.net> - 2011-04-25 06:40 -0400
Re: Can MySql database store images? Tim Watts <tw@dionic.net> - 2011-04-25 11:48 +0100
Re: Can MySql database store images? Jerry Stuckle <jstucklex@attglobal.net> - 2011-04-25 07:28 -0400
Re: Can MySql database store images? Tim Watts <tw@dionic.net> - 2011-04-25 13:36 +0100
Re: Can MySql database store images? Jerry Stuckle <jstucklex@attglobal.net> - 2011-04-25 09:17 -0400
Re: Can MySql database store images? Tim Watts <tw@dionic.net> - 2011-04-25 14:30 +0100
Re: Can MySql database store images? The Natural Philosopher <tnp@invalid.invalid> - 2011-04-25 18:13 +0100
Re: Can MySql database store images? Jerry Stuckle <jstucklex@attglobal.net> - 2011-04-25 19:37 -0400
Re: Can MySql database store images? Jerry Stuckle <jstucklex@attglobal.net> - 2011-04-25 19:35 -0400
Re: Can MySql database store images? "Robert Crandal" <rcranz143101@gmail.com> - 2011-04-24 13:13 -0700
Re: Can MySql database store images? Jerry Stuckle <jstucklex@attglobal.net> - 2011-04-24 17:35 -0400
Re: Can MySql database store images? Axel Schwenke <axel.schwenke@gmx.de> - 2011-04-24 21:29 +0200
Re: Can MySql database store images? "Robert Crandal" <rcranz143101@gmail.com> - 2011-04-24 14:37 -0700
Re: Can MySql database store images? Axel Schwenke <axel.schwenke@gmx.de> - 2011-04-25 00:41 +0200
Re: Can MySql database store images? Jerry Stuckle <jstucklex@attglobal.net> - 2011-04-24 20:16 -0400
Re: Can MySql database store images? Axel Schwenke <axel.schwenke@gmx.de> - 2011-04-25 12:12 +0200
Re: Can MySql database store images? Jerry Stuckle <jstucklex@attglobal.net> - 2011-04-25 07:31 -0400
Re: Can MySql database store images? Tim Watts <tw@dionic.net> - 2011-04-25 08:43 +0100
Re: Can MySql database store images? Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2011-05-01 09:59 +0200
Re: Can MySql database store images? Jerry Stuckle <jstucklex@attglobal.net> - 2011-04-24 20:03 -0400
Re: Can MySql database store images? Jerry Stuckle <jstucklex@attglobal.net> - 2011-04-24 17:39 -0400
Re: Can MySql database store images? Axel Schwenke <axel.schwenke@gmx.de> - 2011-04-25 00:46 +0200
Re: Can MySql database store images? Jerry Stuckle <jstucklex@attglobal.net> - 2011-04-24 20:18 -0400
Re: Can MySql database store images? Luuk <Luuk@invalid.lan> - 2011-04-25 12:13 +0200
Re: Can MySql database store images? Jerry Stuckle <jstucklex@attglobal.net> - 2011-04-25 06:43 -0400
Re: Can MySql database store images? Luuk <Luuk@invalid.lan> - 2011-04-25 13:40 +0200
Re: Can MySql database store images? The Natural Philosopher <tnp@invalid.invalid> - 2011-04-25 12:43 +0100
Re: Can MySql database store images? Jerry Stuckle <jstucklex@attglobal.net> - 2011-04-25 09:19 -0400
Re: Can MySql database store images? Luuk <Luuk@invalid.lan> - 2011-04-25 16:46 +0200
Page 4 of 6 — ← Prev page 1 2 3 [4] 5 6 Next page →
| From | Tim Watts <tw@dionic.net> |
|---|---|
| Date | 2011-04-25 13:42 +0100 |
| Message-ID | <mq6g88-21a.ln1@squidward.dionic.net> |
| In reply to | #662 |
Jerry Stuckle wrote: > I'm saying a university should know better than to try to cram so many > users into one server. > >> Ditto research: The group who really needs a high end dedicated database >> system will be paying for it themselves. The general purpose host is a >> dept funded catchall for the groups who need a modest shared resource. >> >> Which bit of that does not count as good design and sensible allocation >> of resources? >> >> Cheers >> >> tim >> > > To start with, hundreds of users on one server, especially in a > university environment. But that's also off topic here. > Oh please. In your world I suppose the university has infinite funds to slap together a monster system. In the real world, one Postgresql server (could just as well be MySQL) can service the teaching needs of serveral hundred compsci students ding exercises and project work (they don't hit it all at once but their DBs remain on the machine for the life of the student) or a hundred researchers without overloading. Or do you think it is a good idea to divert funds from networking, general purpose filestore, backups or whatever to provide a cabinet full of RDBMS hosts so that sloppy programmers can get away with being inefficient? -- Tim Watts
[toc] | [prev] | [next] | [standalone]
| From | Jerry Stuckle <jstucklex@attglobal.net> |
|---|---|
| Date | 2011-04-25 09:12 -0400 |
| Message-ID | <ip3rvr$l7j$2@dont-email.me> |
| In reply to | #671 |
On 4/25/2011 8:42 AM, Tim Watts wrote: > Jerry Stuckle wrote: > > >> I'm saying a university should know better than to try to cram so many >> users into one server. >> >>> Ditto research: The group who really needs a high end dedicated database >>> system will be paying for it themselves. The general purpose host is a >>> dept funded catchall for the groups who need a modest shared resource. >>> >>> Which bit of that does not count as good design and sensible allocation >>> of resources? >>> >>> Cheers >>> >>> tim >>> >> >> To start with, hundreds of users on one server, especially in a >> university environment. But that's also off topic here. >> > > Oh please. In your world I suppose the university has infinite funds to slap > together a monster system. In the real world, one Postgresql server (could > just as well be MySQL) can service the teaching needs of serveral hundred > compsci students ding exercises and project work (they don't hit it all at > once but their DBs remain on the machine for the life of the student) or a > hundred researchers without overloading. > > Or do you think it is a good idea to divert funds from networking, general > purpose filestore, backups or whatever to provide a cabinet full of RDBMS > hosts so that sloppy programmers can get away with being inefficient? > You're the one who pointed this out as an example of limiting usage. I just pointed out how poor the setup was. And yes, in my world, universities have the ability to provide the necessary equipment to properly support the needs of their students. But them maybe they use their funds more wisely and don't spend 1000+ pounds per server. They buy in bulk and get much better prices - as do large datacenters, for which you example is a small corner of their operation. -- ================== Remove the "x" from my email address Jerry Stuckle JDS Computer Training Corp. jstucklex@attglobal.net ==================
[toc] | [prev] | [next] | [standalone]
| From | Tim Watts <tw@dionic.net> |
|---|---|
| Date | 2011-04-25 14:23 +0100 |
| Message-ID | <279g88-67j.ln1@squidward.dionic.net> |
| In reply to | #675 |
Jerry Stuckle wrote: > You're the one who pointed this out as an example of limiting usage. I > just pointed out how poor the setup was. Good design does not equate with limitless provision of resources. I really don't know what what universe you live in, but most of the rest of us have finite time and funding and design systems to work well given what we have. BTW - A "poor system" would be one (as I have seen in my travels) where there are no backups, no config management and no disaster recovery. The systems I have mentioned met all their design goals and were properly maintained and backup up - something that doesn't happen in a lot of places I've come across. So save your condescending comments for places that deserve it. -- Tim Watts
[toc] | [prev] | [next] | [standalone]
| From | Jerry Stuckle <jstucklex@attglobal.net> |
|---|---|
| Date | 2011-04-25 19:31 -0400 |
| Message-ID | <ip5094$234$2@dont-email.me> |
| In reply to | #679 |
On 4/25/2011 9:23 AM, Tim Watts wrote: > Jerry Stuckle wrote: > > >> You're the one who pointed this out as an example of limiting usage. I >> just pointed out how poor the setup was. > > Good design does not equate with limitless provision of resources. I really > don't know what what universe you live in, but most of the rest of us have > finite time and funding and design systems to work well given what we have. > Nope. Good design equates with maximized use of available resources. Everyone has limits in which they work. You need to figure out how to use those resources better. > BTW - A "poor system" would be one (as I have seen in my travels) where > there are no backups, no config management and no disaster recovery. > > The systems I have mentioned met all their design goals and were properly > maintained and backup up - something that doesn't happen in a lot of places > I've come across. So save your condescending comments for places that > deserve it. > We're not talking about "a lot of places you've come across". We're talking about your system. And how poorly designed it seems to be. But it's also off topic in this newsgroup so I will not continue. -- ================== Remove the "x" from my email address Jerry Stuckle JDS Computer Training Corp. jstucklex@attglobal.net ==================
[toc] | [prev] | [next] | [standalone]
| From | "Mr. B-o-B" <mr.chew.baka@gmail.com> |
|---|---|
| Date | 2011-04-25 20:30 -0500 |
| Message-ID | <alpine.LNX.2.00.1104252019310.10907@conan.grunners.com> |
| In reply to | #652 |
Jerry Stuckle cried from the depths of the abyss... > I've seen hosts like this before - too cheap to buy the proper > equipment. > > Even if they bought all the hardware themselves they're > talking well under $1000. Fascinating! I am curious to know what kind of hardware specs you are basing well under $1000.00, and still in the > too cheap arena.
[toc] | [prev] | [next] | [standalone]
| From | The Natural Philosopher <tnp@invalid.invalid> |
|---|---|
| Date | 2011-04-25 12:21 +0100 |
| Message-ID | <ip3lf4$10n$4@news.albasani.net> |
| In reply to | #611 |
Tim Watts wrote: > The Natural Philosopher wrote: > > >> The only advantages of a flat file system are that any incompetent >> programmer can make it work. > > It may also be the case that you are using a shared/hosted MySQL host which > is not designed for bulk data storage but you do have an additional > filsesystem to one side. > > which could run mysql as well :-) >
[toc] | [prev] | [next] | [standalone]
| From | Tim Watts <tw@dionic.net> |
|---|---|
| Date | 2011-04-25 13:46 +0100 |
| Message-ID | <m27g88-21a.ln1@squidward.dionic.net> |
| In reply to | #661 |
The Natural Philosopher wrote: > Tim Watts wrote: >> The Natural Philosopher wrote: >> >> >>> The only advantages of a flat file system are that any incompetent >>> programmer can make it work. >> >> It may also be the case that you are using a shared/hosted MySQL host >> which is not designed for bulk data storage but you do have an additional >> filsesystem to one side. >> >> > > which could run mysql as well :-) > No it can't - in my shop at least. Fileservers were kept deliberately simple and lightweight software wise - because I want them to server files efficiently, not have non deterministic response times due to some random person doing some DB stuff. I'm doing enough battle with a SAN right now that's I've inherited to find out which of 60 odd VMWare hosts are causing it to overload. This is a different scenario and job to the one where I had a room full of physical mchines BTW. There are times that physical seggregation is a good thing... :) -- Tim Watts
[toc] | [prev] | [next] | [standalone]
| From | Jerry Stuckle <jstucklex@attglobal.net> |
|---|---|
| Date | 2011-04-24 13:23 -0400 |
| Message-ID | <ip1mb9$783$1@dont-email.me> |
| In reply to | #605 |
On 4/24/2011 10:27 AM, Luuk wrote: > On 24-04-2011 14:42, Jerry Stuckle wrote: >> On 4/24/2011 2:47 AM, Robert Crandal wrote: >>> I just started learning about MySql in order to start building >>> a website that stores a database of user information. I'm thinking >>> that I want my database to keep track of user accounts, user profiles, >>> and user information, etc.. etc... >>> >>> I am planning to allow each user to upload as many photos as >>> they want into their personal account space, but my problem is >>> that I don't know WHERE to store an unknown number of images >>> in each user account. Can I store a collection of images in the >>> MySql database somewhere? How? Also, what are some other >>> ways to do this? >>> >>> Thank you! >>> >>> >> >> People have been using relational databases to store images for over 25 >> years that I'm aware of - we were doing it at IBM in the mid-80's. They >> store images just fine, and the more images you have, the better they >> do. Just use a BLOB datatype. > > People are useing filesystems to store images even longer than this 25 > years..... > Only because they existed for longer than that. >> >> The only downside is you can't serve the image directly from the >> database, but it just takes a short script do do so. Not a real big thing. >> >> There are a lot of advantages to using a database. For instance, if you >> just store the filename in the database, what happens when someone >> deletes the image? Or what if the filename is deleted from the database >> but the file still exists (orphaned file). > > That has nothing to do with filesystems or databases, but more with > security, It has EVERYTHING to do with data consistency. You don't want a database to point to a file which no longer exists, for instance. Nor do you want a file which is no longer pointed to by the database (and therefore unused). > What is someone does run a SQL script on your database like: > DELETE FROM table_with_images; > Your data will still be consistent. >> >> Also, file systems don't do well with thousands of users and hundreds of >> thousands of images - they just weren't made to handle that many >> individual files. RDBs such as MySQL, OTOH, easily handles millions of >> users and hundreds of millions of images. >> >> Remember- a file system is just a non-relational database. It's good >> for some things but not everything. > > > I dont think there is a relation between the images, ...? > so storing them in a database wont give any advantage. > Sure there is. There is a direct relationship between a user and his avatar on a forum, for instance. Also a direct relationship between a picture of a product and its description on a shopping site. In fact, most images ARE related to something - very few images are completely stand-alone. -- ================== Remove the "x" from my email address Jerry Stuckle JDS Computer Training Corp. jstucklex@attglobal.net ==================
[toc] | [prev] | [next] | [standalone]
| From | Luuk <Luuk@invalid.lan> |
|---|---|
| Date | 2011-04-24 20:31 +0200 |
| Message-ID | <4db46c71$0$81485$e4fe514c@news.xs4all.nl> |
| In reply to | #609 |
On 24-04-2011 19:23, Jerry Stuckle wrote: > On 4/24/2011 10:27 AM, Luuk wrote: >> On 24-04-2011 14:42, Jerry Stuckle wrote: >>> On 4/24/2011 2:47 AM, Robert Crandal wrote: >>>> I just started learning about MySql in order to start building >>>> a website that stores a database of user information. I'm thinking >>>> that I want my database to keep track of user accounts, user profiles, >>>> and user information, etc.. etc... >>>> >>>> I am planning to allow each user to upload as many photos as >>>> they want into their personal account space, but my problem is >>>> that I don't know WHERE to store an unknown number of images >>>> in each user account. Can I store a collection of images in the >>>> MySql database somewhere? How? Also, what are some other >>>> ways to do this? >>>> >>>> Thank you! >>>> >>>> >>> >>> People have been using relational databases to store images for over 25 >>> years that I'm aware of - we were doing it at IBM in the mid-80's. They >>> store images just fine, and the more images you have, the better they >>> do. Just use a BLOB datatype. >> >> People are useing filesystems to store images even longer than this 25 >> years..... >> > > Only because they existed for longer than that. > >>> >>> The only downside is you can't serve the image directly from the >>> database, but it just takes a short script do do so. Not a real big >>> thing. >>> >>> There are a lot of advantages to using a database. For instance, if you >>> just store the filename in the database, what happens when someone >>> deletes the image? Or what if the filename is deleted from the database >>> but the file still exists (orphaned file). >> >> That has nothing to do with filesystems or databases, but more with >> security, > > It has EVERYTHING to do with data consistency. You don't want a > database to point to a file which no longer exists, for instance. Nor > do you want a file which is no longer pointed to by the database (and > therefore unused). > >> What is someone does run a SQL script on your database like: >> DELETE FROM table_with_images; >> > > Your data will still be consistent. > >>> >>> Also, file systems don't do well with thousands of users and hundreds of >>> thousands of images - they just weren't made to handle that many >>> individual files. RDBs such as MySQL, OTOH, easily handles millions of >>> users and hundreds of millions of images. >>> >>> Remember- a file system is just a non-relational database. It's good >>> for some things but not everything. >> >> >> I dont think there is a relation between the images, ...? >> so storing them in a database wont give any advantage. >> > > Sure there is. There is a direct relationship between a user and his > avatar on a forum, for instance. Also a direct relationship between a > picture of a product and its description on a shopping site. > > In fact, most images ARE related to something - very few images are > completely stand-alone. > ok, But someone who is deleting a file from his system is doing not much better, or worse, than the dba who's doing a DELETE from a 'random' table. A system is as consistent as its creator.... -- Luuk
[toc] | [prev] | [next] | [standalone]
| From | Jerry Stuckle <jstucklex@attglobal.net> |
|---|---|
| Date | 2011-04-24 14:48 -0400 |
| Message-ID | <ip1r9c$5pd$3@dont-email.me> |
| In reply to | #612 |
On 4/24/2011 2:31 PM, Luuk wrote: > On 24-04-2011 19:23, Jerry Stuckle wrote: >> On 4/24/2011 10:27 AM, Luuk wrote: >>> On 24-04-2011 14:42, Jerry Stuckle wrote: >>>> On 4/24/2011 2:47 AM, Robert Crandal wrote: >>>>> I just started learning about MySql in order to start building >>>>> a website that stores a database of user information. I'm thinking >>>>> that I want my database to keep track of user accounts, user profiles, >>>>> and user information, etc.. etc... >>>>> >>>>> I am planning to allow each user to upload as many photos as >>>>> they want into their personal account space, but my problem is >>>>> that I don't know WHERE to store an unknown number of images >>>>> in each user account. Can I store a collection of images in the >>>>> MySql database somewhere? How? Also, what are some other >>>>> ways to do this? >>>>> >>>>> Thank you! >>>>> >>>>> >>>> >>>> People have been using relational databases to store images for over 25 >>>> years that I'm aware of - we were doing it at IBM in the mid-80's. They >>>> store images just fine, and the more images you have, the better they >>>> do. Just use a BLOB datatype. >>> >>> People are useing filesystems to store images even longer than this 25 >>> years..... >>> >> >> Only because they existed for longer than that. >> >>>> >>>> The only downside is you can't serve the image directly from the >>>> database, but it just takes a short script do do so. Not a real big >>>> thing. >>>> >>>> There are a lot of advantages to using a database. For instance, if you >>>> just store the filename in the database, what happens when someone >>>> deletes the image? Or what if the filename is deleted from the database >>>> but the file still exists (orphaned file). >>> >>> That has nothing to do with filesystems or databases, but more with >>> security, >> >> It has EVERYTHING to do with data consistency. You don't want a >> database to point to a file which no longer exists, for instance. Nor >> do you want a file which is no longer pointed to by the database (and >> therefore unused). >> >>> What is someone does run a SQL script on your database like: >>> DELETE FROM table_with_images; >>> >> >> Your data will still be consistent. >> >>>> >>>> Also, file systems don't do well with thousands of users and hundreds of >>>> thousands of images - they just weren't made to handle that many >>>> individual files. RDBs such as MySQL, OTOH, easily handles millions of >>>> users and hundreds of millions of images. >>>> >>>> Remember- a file system is just a non-relational database. It's good >>>> for some things but not everything. >>> >>> >>> I dont think there is a relation between the images, ...? >>> so storing them in a database wont give any advantage. >>> >> >> Sure there is. There is a direct relationship between a user and his >> avatar on a forum, for instance. Also a direct relationship between a >> picture of a product and its description on a shopping site. >> >> In fact, most images ARE related to something - very few images are >> completely stand-alone. >> > > ok, > But someone who is deleting a file from his system is doing not much > better, or worse, than the dba who's doing a DELETE from a 'random' table. > Sure he is. You can guarantee a database is always consistent. > A system is as consistent as its creator.... > A database can be designed to be 100% consistent 100% of the time. And one other thing - sure, people have been storing images in filesystems for a long time. And some people continue to use old technology, even when something better comes along. -- ================== Remove the "x" from my email address Jerry Stuckle JDS Computer Training Corp. jstucklex@attglobal.net ==================
[toc] | [prev] | [next] | [standalone]
| From | Luuk <Luuk@invalid.lan> |
|---|---|
| Date | 2011-04-24 21:11 +0200 |
| Message-ID | <4db475cc$0$81485$e4fe514c@news.xs4all.nl> |
| In reply to | #615 |
On 24-04-2011 20:48, Jerry Stuckle wrote: > On 4/24/2011 2:31 PM, Luuk wrote: >> On 24-04-2011 19:23, Jerry Stuckle wrote: >>> On 4/24/2011 10:27 AM, Luuk wrote: >>>> On 24-04-2011 14:42, Jerry Stuckle wrote: >>>>> On 4/24/2011 2:47 AM, Robert Crandal wrote: >>>>>> I just started learning about MySql in order to start building >>>>>> a website that stores a database of user information. I'm thinking >>>>>> that I want my database to keep track of user accounts, user >>>>>> profiles, >>>>>> and user information, etc.. etc... >>>>>> >>>>>> I am planning to allow each user to upload as many photos as >>>>>> they want into their personal account space, but my problem is >>>>>> that I don't know WHERE to store an unknown number of images >>>>>> in each user account. Can I store a collection of images in the >>>>>> MySql database somewhere? How? Also, what are some other >>>>>> ways to do this? >>>>>> >>>>>> Thank you! >>>>>> >>>>>> >>>>> >>>>> People have been using relational databases to store images for >>>>> over 25 >>>>> years that I'm aware of - we were doing it at IBM in the mid-80's. >>>>> They >>>>> store images just fine, and the more images you have, the better they >>>>> do. Just use a BLOB datatype. >>>> >>>> People are useing filesystems to store images even longer than this 25 >>>> years..... >>>> >>> >>> Only because they existed for longer than that. >>> >>>>> >>>>> The only downside is you can't serve the image directly from the >>>>> database, but it just takes a short script do do so. Not a real big >>>>> thing. >>>>> >>>>> There are a lot of advantages to using a database. For instance, >>>>> if you >>>>> just store the filename in the database, what happens when someone >>>>> deletes the image? Or what if the filename is deleted from the >>>>> database >>>>> but the file still exists (orphaned file). >>>> >>>> That has nothing to do with filesystems or databases, but more with >>>> security, >>> >>> It has EVERYTHING to do with data consistency. You don't want a >>> database to point to a file which no longer exists, for instance. Nor >>> do you want a file which is no longer pointed to by the database (and >>> therefore unused). >>> >>>> What is someone does run a SQL script on your database like: >>>> DELETE FROM table_with_images; >>>> >>> >>> Your data will still be consistent. >>> >>>>> >>>>> Also, file systems don't do well with thousands of users and >>>>> hundreds of >>>>> thousands of images - they just weren't made to handle that many >>>>> individual files. RDBs such as MySQL, OTOH, easily handles >>>>> millions of >>>>> users and hundreds of millions of images. >>>>> >>>>> Remember- a file system is just a non-relational database. It's good >>>>> for some things but not everything. >>>> >>>> >>>> I dont think there is a relation between the images, ...? >>>> so storing them in a database wont give any advantage. >>>> >>> >>> Sure there is. There is a direct relationship between a user and his >>> avatar on a forum, for instance. Also a direct relationship between a >>> picture of a product and its description on a shopping site. >>> >>> In fact, most images ARE related to something - very few images are >>> completely stand-alone. >>> >> >> ok, >> But someone who is deleting a file from his system is doing not much >> better, or worse, than the dba who's doing a DELETE from a 'random' >> table. >> > > Sure he is. You can guarantee a database is always consistent. > > >> A system is as consistent as its creator.... >> > > A database can be designed to be 100% consistent 100% of the time. > > And one other thing - sure, people have been storing images in > filesystems for a long time. And some people continue to use old > technology, even when something better comes along. > > OK, now you convinced me...... (or not, but that would be OT ) ;) -- Luuk
[toc] | [prev] | [next] | [standalone]
| From | Axel Schwenke <axel.schwenke@gmx.de> |
|---|---|
| Date | 2011-04-24 21:24 +0200 |
| Message-ID | <nv9e88-1sa.ln1@xl.homelinux.org> |
| In reply to | #602 |
Jerry Stuckle <jstucklex@attglobal.net> wrote: [other nonsense snipped] > Also, file systems don't do well with thousands of users and hundreds of > thousands of images - they just weren't made to handle that many > individual files. RDBs such as MySQL, OTOH, easily handles millions of > users and hundreds of millions of images. > > Remember- a file system is just a non-relational database. It's good > for some things but not everything. Wrong! Files systems are much better nowadays. Since directories are no longer linear lists, but trees, all filesystems can easily cope with millions of images in a single directory. http://mysqldump.azundris.com/archives/37-Serving-Images-from-a-File-System.html For the edge cases, where holding the images in the database is considered a good thing, there is a little known technique, called "statification" (well, Kris calls it like so). I used it about 10 years before we blogged about it and did not give it a name at all... http://mysqldump.azundris.com/archives/59-Statification.html Our edge case was, that we used MySQL replication to distribute content to our web servers. In fact the images were fed into our redaction system by editors (and stored as blobs there, besides text snippets). The publicing system pushed them to the master database. And replication distributed them to the web server farm. A 404 handler there copied each image to the local disk when it was accessed first. All nice and simple. Static content. Delivered fast. Cacheable. XL
[toc] | [prev] | [next] | [standalone]
| From | Jerry Stuckle <jstucklex@attglobal.net> |
|---|---|
| Date | 2011-04-24 17:34 -0400 |
| Message-ID | <ip250e$nd9$1@dont-email.me> |
| In reply to | #617 |
On 4/24/2011 3:24 PM, Axel Schwenke wrote: > Jerry Stuckle<jstucklex@attglobal.net> wrote: > > [other nonsense snipped] > >> Also, file systems don't do well with thousands of users and hundreds of >> thousands of images - they just weren't made to handle that many >> individual files. RDBs such as MySQL, OTOH, easily handles millions of >> users and hundreds of millions of images. >> >> Remember- a file system is just a non-relational database. It's good >> for some things but not everything. > > Wrong! Files systems are much better nowadays. Since directories are > no longer linear lists, but trees, all filesystems can easily cope > with millions of images in a single directory. > > http://mysqldump.azundris.com/archives/37-Serving-Images-from-a-File-System.html > Yes, you can fudge almost any figures you want. But the fact is, I have yet to see a file system which can handle millions of files in one directory in a real operating environment as well as a good database can handle them. Databases are made to handle millions of rows; file systems are not made to handle millions of files. > > For the edge cases, where holding the images in the database is > considered a good thing, there is a little known technique, called > "statification" (well, Kris calls it like so). I used it about 10 > years before we blogged about it and did not give it a name at all... > > http://mysqldump.azundris.com/archives/59-Statification.html > > Our edge case was, that we used MySQL replication to distribute content > to our web servers. In fact the images were fed into our redaction > system by editors (and stored as blobs there, besides text snippets). > The publicing system pushed them to the master database. And > replication distributed them to the web server farm. A 404 handler > there copied each image to the local disk when it was accessed first. > > All nice and simple. Static content. Delivered fast. Cacheable. > > > XL Additionally, RDBMS's can partition data for faster access, i.e. across multiple disks or even multiple systems. Filesystems cannot do that transparently. There are any number of ways you can tune a database for faster access to images; such tunings are limited or even non-existent in file systems. Properly tuned, I suspect his statistics could be much different. Maybe that attitude is another reason why experienced dba's consider MySQL to be a toy database. -- ================== Remove the "x" from my email address Jerry Stuckle JDS Computer Training Corp. jstucklex@attglobal.net ==================
[toc] | [prev] | [next] | [standalone]
| From | Luuk <Luuk@invalid.lan> |
|---|---|
| Date | 2011-04-25 12:04 +0200 |
| Message-ID | <4db54728$0$81481$e4fe514c@news.xs4all.nl> |
| In reply to | #628 |
On 24-04-2011 23:34, Jerry Stuckle wrote: > Additionally, RDBMS's can partition data for faster access, i.e. across > multiple disks or even multiple systems. Filesystems cannot do that > transparently. File systems can do that, they invented something like directory's for that. A different toy needs different tools... -- Luuk
[toc] | [prev] | [next] | [standalone]
| From | Jerry Stuckle <jstucklex@attglobal.net> |
|---|---|
| Date | 2011-04-25 06:40 -0400 |
| Message-ID | <ip3j2r$q59$2@dont-email.me> |
| In reply to | #647 |
On 4/25/2011 6:04 AM, Luuk wrote: > On 24-04-2011 23:34, Jerry Stuckle wrote: >> Additionally, RDBMS's can partition data for faster access, i.e. across >> multiple disks or even multiple systems. Filesystems cannot do that >> transparently. > > File systems can do that, they invented something like directory's for that. > > A different toy needs different tools... > Name a file system which transparently partitions a directory across multiple systems. -- ================== Remove the "x" from my email address Jerry Stuckle JDS Computer Training Corp. jstucklex@attglobal.net ==================
[toc] | [prev] | [next] | [standalone]
| From | Tim Watts <tw@dionic.net> |
|---|---|
| Date | 2011-04-25 11:48 +0100 |
| Message-ID | <840g88-ece.ln1@squidward.dionic.net> |
| In reply to | #653 |
Jerry Stuckle wrote: > On 4/25/2011 6:04 AM, Luuk wrote: >> On 24-04-2011 23:34, Jerry Stuckle wrote: >>> Additionally, RDBMS's can partition data for faster access, i.e. across >>> multiple disks or even multiple systems. Filesystems cannot do that >>> transparently. >> >> File systems can do that, they invented something like directory's for >> that. >> >> A different toy needs different tools... >> > > Name a file system which transparently partitions a directory across > multiple systems. > ZFS Any file system on top of LVM or EVMS. -- Tim Watts
[toc] | [prev] | [next] | [standalone]
| From | Jerry Stuckle <jstucklex@attglobal.net> |
|---|---|
| Date | 2011-04-25 07:28 -0400 |
| Message-ID | <ip3lt2$f67$2@dont-email.me> |
| In reply to | #655 |
On 4/25/2011 6:48 AM, Tim Watts wrote: > Jerry Stuckle wrote: > >> On 4/25/2011 6:04 AM, Luuk wrote: >>> On 24-04-2011 23:34, Jerry Stuckle wrote: >>>> Additionally, RDBMS's can partition data for faster access, i.e. across >>>> multiple disks or even multiple systems. Filesystems cannot do that >>>> transparently. >>> >>> File systems can do that, they invented something like directory's for >>> that. >>> >>> A different toy needs different tools... >>> >> >> Name a file system which transparently partitions a directory across >> multiple systems. >> > > ZFS > > Any file system on top of LVM or EVMS. > And if I'm not mistaken, it's subdirectories which are spread across multiple disks - not files in one directory. -- ================== Remove the "x" from my email address Jerry Stuckle JDS Computer Training Corp. jstucklex@attglobal.net ==================
[toc] | [prev] | [next] | [standalone]
| From | Tim Watts <tw@dionic.net> |
|---|---|
| Date | 2011-04-25 13:36 +0100 |
| Message-ID | <bg6g88-ho8.ln1@squidward.dionic.net> |
| In reply to | #663 |
Jerry Stuckle wrote: > On 4/25/2011 6:48 AM, Tim Watts wrote: >> Jerry Stuckle wrote: >> >>> On 4/25/2011 6:04 AM, Luuk wrote: >>>> On 24-04-2011 23:34, Jerry Stuckle wrote: >>>>> Additionally, RDBMS's can partition data for faster access, i.e. >>>>> across >>>>> multiple disks or even multiple systems. Filesystems cannot do that >>>>> transparently. >>>> >>>> File systems can do that, they invented something like directory's for >>>> that. >>>> >>>> A different toy needs different tools... >>>> >>> >>> Name a file system which transparently partitions a directory across >>> multiple systems. >>> >> >> ZFS >> >> Any file system on top of LVM or EVMS. >> > > And if I'm not mistaken, it's subdirectories which are spread across > multiple disks - not files in one directory. > I'm not sure in the case of ZFS, but with LVM or EVMS (though that's pretty dead now) the spreading is done at the block level so what bits of what files end up where is pretty random. LVM is not filesystem aware and the FS on top has only the awareness of LVM that may have been hinted to it at mkfs time (ie for optimising stripe size etc) and that cannot be trusted as absolute. ZFS is of course aware of the FS and the block devices as it spans all the layers, but as to whether it deliberately tries to keep one directory localised I do not know - but it would seem to be an unecessary and pointless limitation for it to try to do so. -- Tim Watts
[toc] | [prev] | [next] | [standalone]
| From | Jerry Stuckle <jstucklex@attglobal.net> |
|---|---|
| Date | 2011-04-25 09:17 -0400 |
| Message-ID | <ip3s9a$kts$1@dont-email.me> |
| In reply to | #670 |
On 4/25/2011 8:36 AM, Tim Watts wrote: > Jerry Stuckle wrote: > >> On 4/25/2011 6:48 AM, Tim Watts wrote: >>> Jerry Stuckle wrote: >>> >>>> On 4/25/2011 6:04 AM, Luuk wrote: >>>>> On 24-04-2011 23:34, Jerry Stuckle wrote: >>>>>> Additionally, RDBMS's can partition data for faster access, i.e. >>>>>> across >>>>>> multiple disks or even multiple systems. Filesystems cannot do that >>>>>> transparently. >>>>> >>>>> File systems can do that, they invented something like directory's for >>>>> that. >>>>> >>>>> A different toy needs different tools... >>>>> >>>> >>>> Name a file system which transparently partitions a directory across >>>> multiple systems. >>>> >>> >>> ZFS >>> >>> Any file system on top of LVM or EVMS. >>> >> >> And if I'm not mistaken, it's subdirectories which are spread across >> multiple disks - not files in one directory. >> > > I'm not sure in the case of ZFS, but with LVM or EVMS (though that's pretty > dead now) the spreading is done at the block level so what bits of what > files end up where is pretty random. LVM is not filesystem aware and the FS > on top has only the awareness of LVM that may have been hinted to it at mkfs > time (ie for optimising stripe size etc) and that cannot be trusted as > absolute. > > ZFS is of course aware of the FS and the block devices as it spans all the > layers, but as to whether it deliberately tries to keep one directory > localised I do not know - but it would seem to be an unecessary and > pointless limitation for it to try to do so. > So what you're saying is that the same file may end up on multiple different servers. And if any of those servers failed, a huge number of files would potentially be unavailable - or at least parts of them would, which is just as bad. And you have no control over what gets stored where, so you can't, for instance, put the most accessed files on the local disk while other, less used files, are on remote disks. Sounds like a total disaster just waiting to happen. OTOH, with databases, you can partition the database so that more commonly used data is available from the local disk, while lesser-used data can be pulled from other systems. And in no case do you have a row split across multiple systems, so you have just limited the rows affected by a system failure. -- ================== Remove the "x" from my email address Jerry Stuckle JDS Computer Training Corp. jstucklex@attglobal.net ==================
[toc] | [prev] | [next] | [standalone]
| From | Tim Watts <tw@dionic.net> |
|---|---|
| Date | 2011-04-25 14:30 +0100 |
| Message-ID | <8l9g88-3uk.ln1@squidward.dionic.net> |
| In reply to | #677 |
Jerry Stuckle wrote: > > So what you're saying is that the same file may end up on multiple > different servers. And if any of those servers failed, a huge number of > files would potentially be unavailable - or at least parts of them > would, which is just as bad. And you have no control over what gets > stored where, so you can't, for instance, put the most accessed files on > the local disk while other, less used files, are on remote disks. > > Sounds like a total disaster just waiting to happen. You claim to have decades of experience and yet you don't know how ZFS or LVM work? Where did I say "multiple servers"??? I said "multiple block devices" ie muliple disks. If you want multiple servers, use Lustre or somesuch - in which case you have the option of replication to avoid that problem. But you're the one suddenly bringing multiple servers into the equation. I think you have run out of good points to argue so you are just muddying the waters on purpose. > OTOH, with databases, you can partition the database so that more > commonly used data is available from the local disk, while lesser-used > data can be pulled from other systems. And in no case do you have a row > split across multiple systems, so you have just limited the rows > affected by a system failure. > You are referring to Federated MySQL DBs? -- Tim Watts
[toc] | [prev] | [next] | [standalone]
Page 4 of 6 — ← Prev page 1 2 3 [4] 5 6 Next page →
Back to top | Article view | comp.databases.mysql
csiph-web