Path: csiph.com!x330-a1.tempe.blueboxinc.net!usenet.pasdenom.info!aioe.org!eternal-september.org!feeder.eternal-september.org!.POSTED!not-for-mail From: Tim Watts Newsgroups: comp.databases.mysql Subject: Re: Can MySql database store images? Followup-To: comp.databases.mysql Date: Sun, 24 Apr 2011 20:51:15 +0100 Organization: A noiseless patient Spider Lines: 86 Message-ID: References: <55md88-7pb.ln1@squidward.dionic.net> Mime-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7Bit Injection-Info: mx02.eternal-september.org; posting-host="6oIlEBqCjOm0MjsSUEk5CA"; logging-data="16263"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1/GZ4rKyCK1+Wqxd/JFgiNoIABZImInC9o=" User-Agent: KNode/4.4.6 Cancel-Lock: sha1:PuaL4CgHlHDcS8zOnoDVITttchM= Xref: x330-a1.tempe.blueboxinc.net comp.databases.mysql:619 Jerry Stuckle wrote: > Totally practical. Just back it up locally then transfer whenever you > want. That's how I do filesystem backups, also. That way the backup > isn't being delayed by the network. Yeah - I was kind of considering the case where the total dataset size exceeds the capacity of the link over the backup periodicy - which could be a problem for a very large dataset and a very weak link. But see below: >> But referencing your earlier points about rsync - I've always run >> reverse- incrementals, ie the latest copy is always a full and the >> previous sets are what changed going backwards in time which is ery >> natural for rsync as you know so I don't see any issues with restoration >> from that. >> >> > > It has a tendency to leave files you want deleted. How so? This is a unidirectional sync - rsync is quite capable of fully synchronising the target with th source. Bi-directional syncing is prone to such problems, but that doesn't apply here. >>>> Just my opinion, based on Postgresql - but the principles mostly apply >>>> to MySQL unless it has some particular features to help with the >>>> problems I posed. >>>> >>>> Cheers, >>>> >>>> Tim >>> >>> Just my opinions based on 25 years of experience, starting with DB2 but >>> also including MySQL, Oracle and SQL Server. >>> >> >> That's fair enough - I will not answer for DB2 as I am aware it is a >> pretty powerful system with a lot of funky features, but I will stand by >> my personal preference that I prefer to keep RDBMSs "compact" with any >> lumpy stuff to one side. Note, I don't say it is the *only* way, but it's >> the way I default to advising my users. >> > > Have you ever used a database for images? Yes - briefly when I was playing with some image aware DB bound widgets in a RAD tool. But if developing a web deplyment, I personally would feel it an easier task to keep the image data on the filesystem - even accounting for the double checking necessary. I will admit that most of my opinions on BLOBs were drawn from pre-8.3 postgres where a BLOB was a seperate storage entity and linkage with a column was weak (just an OID) and it was expected that an unmanaged DELETE would lead to orphaned BLOBs - at which point I could see no useful purpose to them. Are MySQL BLOBs tightly tied to the table column they belong to - ie is a DELETE of a row with a BLOB guaranteed to destroy the BLOB too? In which case, I concede it is more of a sensible proposition. >> On an aside, how would you do "incrementals" with MySQL - would you code >> something into the database with triggers, or do something along the >> lines of keep (in Postgres speak) the journals/WAL logs for the >> incrementals? >> >> Cheers >> >> Tim >> > > http://dev.mysql.com/doc/refman/5.5/en/backup-methods.html > > Look down the page for incremental backups. > > Yep - that fits with what I said. Cheers, Tim -- Tim Watts