BLU Discuss list archive
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Discuss] SQL discussion
- Subject: [Discuss] SQL discussion
- From: smallm at panix.com (Mike Small)
- Date: Tue, 13 Jan 2015 11:48:50 -0500
- In-reply-to: <CANiupv6Y=k72K=etq6oKWRm8zSCGYcMTaXx60iD-aeUETS_nZA@mail.gmail.com> (Doug's message of "Tue, 13 Jan 2015 11:35:16 -0500")
- References: <3b5e4d10464b98632f1d45a222c26f73.squirrel@mail.mohawksoft.com> <li67fwq64qk.fsf@panix5.panix.com> <CANiupv6Y=k72K=etq6oKWRm8zSCGYcMTaXx60iD-aeUETS_nZA@mail.gmail.com>
Doug <sweetser at alum.mit.edu> writes: > postgres rocks in my opinion. But I still have a fear: triggers. It is > triggers that blur what I view as a database - place for my data, with > programming, which is to transform the data. There is no universal trigger > language. In postgres, there are a bunch. The trigger code is not so This is a problem. The result where I've been working is that things that would make sense to run in the DB are not. Instead they're written in C++ and run on a different machine. Reams of data gets unnecessarily copied across the network, just because we needed to support multiple RDBMes and didn't feel we could afford to have multiple sets of stored procedures, one for each vendor's language. -- Mike Small smallm at panix.com
- References:
- [Discuss] SQL discussion
- From: markw at mohawksoft.com (markw at mohawksoft.com)
- [Discuss] SQL discussion
- From: smallm at panix.com (Mike Small)
- [Discuss] SQL discussion
- From: sweetser at alum.mit.edu (Doug)
- [Discuss] SQL discussion
- Prev by Date: [Discuss] SQL discussion
- Next by Date: [Discuss] apache -- same old
- Previous by thread: [Discuss] SQL discussion
- Next by thread: [Discuss] SQL discussion
- Index(es):