From mboxrd@z Thu Jan 1 00:00:00 1970 Content-Type: text/plain; charset=windows-1252; format=flowed; delsp=yes Mime-Version: 1.0 (Apple Message framework v1075.2) From: Daniel Lyons In-Reply-To: <509071940909030913q24d0da62x13daa9c04494964f@mail.gmail.com> Date: Thu, 3 Sep 2009 15:50:07 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <003AC6B7-30EB-44F6-B0F6-C5222FE9BC5A@storytotell.org> References: <4A9FA6B5.9020302@maht0x0r.net> <838f0f5ea30688aae8174b6c42844ef9@quanstro.net> <509071940909030913q24d0da62x13daa9c04494964f@mail.gmail.com> To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net> Subject: Re: [9fans] Interested in improving networking in Plan 9 Topicbox-Message-UUID: 62fc34ac-ead5-11e9-9d60-3106f5b1d025 On Sep 3, 2009, at 10:13 AM, Anthony Sorace wrote: > you can do things like > data constraints and validations in the application code, rather than > in the sql database itself, which always feels like this random > bolt-on to the application logic. I think it's useful to think of relational databases as integration =20 technology rather than merely storage technology. Having everything =20 important in the application layer means you have to go through the =20 application layer to do anything. Part of the point of SQL and RDBMSes =20= being so complex is that it liberates the data from any one particular =20= application that wants to access the data. This fact is often =20 forgotten these days because most databases are only accessed through =20= the web via one app. But I usually find that eventually one needs to =20 get at the data directly, for reporting, maintenance or some other =20 task that isn't intrinsically part of the website. Then the database =20 can take on the data management role and make sure you don't make your =20= data incomprehensible, as well as provide you with a little security. Of course, it's best of all if you have a database that supports =20 things like views; otherwise you will need application code to have =20 any abstractions at all. =97 Daniel Lyons