On Jun 30, 8:12 am, Giacomo Tesio <[email protected]> wrote: > > Just an appoint: if you need to store up to 30k in a column, I think that > you are _probably_ doing something wrong... > > A part from Linq, you should consider to move the 30k of datas to idenfiable > locations (like files identified by uri's) and strore in the column the uri > only. > > Let me say that this approach would have a lot of advantages even if you > would query the db via plain ADO.NET + SQL strings... > > BTW, if I would be wrong, I'd really like to know why you have choosen such > approach... > Just to learn something new... ;-)
A 30k field in a column isn't really that much. I'm pretty sure there are a lot of applications using databases to store audio and video and they are going to be storing BLOBs way over 30k. I know Asterisk (www.asterisk.org) allows voicemails to be stored in a database and with a wideband codec the voicemails could be pretty large. In my application's case I am storing user dialplans which are Ruby scripts in the 30k field. I originally started with a 10k limit and am now up to 30k as the size of some user's dialplan scripts keeps going up. Most users have small dialplans of less than 1k. The scripts need to be accessed from multiple processes which can be on different servers and can be regulalrly updated through a web page by users so the database really is the ideal place. A flat file system would be very difficult to administer and manage the cross process access. Regards, Aaron --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "DbLinq" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/dblinq?hl=en -~----------~----~----~----~------~----~------~--~---
