On Sun, Sep 18, 2011 at 11:13 AM, Rajeev Prasad <rp.ne...@yahoo.com> wrote: > if we have data in database and we can process it using sql why > cant we just offer access to that data directly - with all > security and business logic builtin? is this not the age old > issue of how to store and offer data, for which databases were > invented? are we just re-inventing the wheel? adding another > complex code on top of many layers of code?
There are a few reasons. Access to the database requires database credentials. Even if the data is freely readable and writable by anonymous users, you still can't allow anonymous users to freely modify the database structure, or drop the database entirely. :) You could make an 'anonymous' user and ONLY grant them privileges to execute "safe" stored procedures that implement all of the business logic, making it safe to allow anyone to execute them. However, that is very difficult to do, and even more difficult to manage properly. SQL is a rather rudimentary language, designed as a _query_ language. It's more difficult to implement business logic in SQL than in a higher level language like Perl or Java, IMHO. There are other considerations too. If you grant the world direct access to your database management system then any flaw in your database setup or even the database management system itself will leave all of your data completely vulnerable to corruption or loss. A flaw in your application could do the same thing, but I guess the extra layer of abstraction just makes things a little bit safer. It's also easier to write safety-layers in application code to greatly reduce the number of human errors that can have such a drastic effect. For example, using a parameter-based API to feed unsafe data into SQL, rather than manually concatenating a SQL string. The abstraction also makes it easier to make database structure changes without affecting the world. You could change the structure of your database, or your stored procedures, and keep the public Web service API the same; meaning that nobody else needs to rewrite their code. The opposite is true also: you can easily add new Web service calls without any changes to the database. In fact, you don't technically even need to have a database at all. For all anybody using the service knows, the data could be stored in plain XML files, or could be coming from a third party. They don't know how or where it's stored and they shouldn't need to. All they need to know is the Web service API that you expose. A Web service is basically intended for machine interaction. A Web site is typically used for direct human interaction. Technically both can be used by either, but it's more difficult to do. Whether or not you should implement a Web service depends on the type of site that you're creating, and the value of exposing the services (if any) directly to machines. Similarly, you only need to create a Web site (i.e., human-centric) if humans are actually going to directly access your information or interact with your services. Having both is certainly ideal, but you have to evaluate the cost of development (and maintenance) against the practical benefits. -- Brandon McCaig <http://www.bamccaig.com/> <bamcc...@gmail.com> V zrna gur orfg jvgu jung V fnl. Vg qbrfa'g nyjnlf fbhaq gung jnl. Castopulence Software <http://www.castopulence.org/> <bamcc...@castopulence.org> -- To unsubscribe, e-mail: beginners-unsubscr...@perl.org For additional commands, e-mail: beginners-h...@perl.org http://learn.perl.org/
