use Perl

• survey response (Score:1)

  by thinc (3788)

  1. How often have you ported an app from one database engine to another (e.g., MySQL to Oracle)?
  
  Never.
  
  2. How often have you had completely separate apps writing to the same data store (using completely different code bases)?
  
  A couple of times. Putting the logic in the database generally also simplifies data retrieval and storage in the app layer.
  
  3. Do you depend on non-portable database features?
  
  Absolutely.
  
  4. Have you experienced programmers damaging your data because the logic wasn't in the da
• Real world? (Score:1)

  by ChrisDolan (2855)

  Heh, my largest database project so far was on a database with data that was so bad that stored procedures were not even realistic due to the amount of special-casing. We couldn't change the schema because legacy applications still did a lot of the work. We made heavy use of accessors and mutators in Perl to make the data look somewhat less hairy to the business logic.
  
  So, I my responses:
  
  1) porting: nearly never (almost 100% mysql)
  2) multiple apps: on at least two occasions
  3) db features: not often
  4) damag
• Response (Score:1)

  by Enoch (3329)

  How often have you ported an app from one database engine to another (e.g., MySQL to Oracle)?

  Once.

  How often have you had completely separate apps writing to the same data store (using completely different code bases)?

  I would say 50% of the time (but I'm a Middleware Engineer and not a web programmer).

  Do you depend on non-portable database features?

  Quite frequently.

  Have you experienced programmers damaging your data because the logic wasn't in the database layer?

  Actually... not that I c
• Replies and nits (Score:2)

  by VSarkiss (704)

  You have to be careful whenever you use the word "all" or "always" when it comes to computing. :-)

  Generally, the business logic that belongs in the database is usually "data rules", like "an order must have a customer", "a customer must have a name". Business logic that doesn't belong in the database are things like process flow logic. Generally.

  Now on to your questions:

  How often have you ported an app from one database engine to another (e.g., MySQL to Oracle)?

  A few times: Informix to Sybase, pro
• Database Usage (Score:2)

  by ziggy (25)

  (Thinking about 15 years of projects, some web, some not):
  
  1. How often have you ported an app from one database engine to another (e.g., MySQL to Oracle)?
  
  One migration, from RDB to Oracle, but only because Oracle bought RDB, and that was the only path forward. (Come to think of it, that may have just been a re-branded version of RDB, so there was no real migration to speak of.)
  
  Lots of work with custom data storage solutions (as in, write your own database engine), typically because there was an expectatio
• Databases and Data Logic (Score:1)

  by n1vux (1492)

  Short answer -- If you have DBAs who earn their big bucks, do it their way. If not, ask why not; and do it so that your next project will be easier. Data logc belongs in the DB. Logic specific to a specific use of the data belongs in the specific application.

  Business logic in the application:
  Stored procedures and triggers are typically hidden. DB Neutral

  Logic that is data centric belongs with the Data, so that it's programming language neutral. I'm more likely to have programs in two different langu

  --
  Bill
  # I had a sig when sigs were cool
  use Sig;
• Survey Response (Score:1)

  by nmcfarl (291)

  How often have you ported an app from one database engine to another (e.g., MySQL to Oracle)?

  3 times from MySQL to PostgreSQL, but they were all small DBs. A couple times from Access to MS SQL but I'm not sure how much that counts.

  I've never done this when there was more than app using the DB.

  How often have you had completely separate apps writing to the same data store (using completely different code bases)?

  Many, many times.

  Do you depend on non-portable database features?

  Always -
• survey response (Score:1)

  by plural (4499)

  1. How often have you ported an app from one database engine to another (e.g., MySQL to Oracle)? only small applications. 2. How often have you had completely separate apps writing to the same data store (using completely different code bases)? every day. it is maddening. 3. Do you depend on non-portable database features? yes, but they are mainly isolated to a a library that generates the sql we need, so it doesn't frighten me (well, not completely, anyway) to need to change it. 4. Have
• Response. (Score:1)

  by jarich (4909)

  1. How often have you ported an app from one database engine to another (e.g., MySQL to Oracle)?

  Once in 8 years.

  2. How often have you had completely separate apps writing to the same data store (using completely different code bases)?

  About a dozen (still maintained) projects.

  3. Do you depend on non-portable database features?

  It depends. Beyond default values, not nulls, primary keys, foreign keys, autoincrement and constraints (cascade delete...) I generally don't encode
• "It's trivial to inspect and change." is a biggie (Score:1)

  by markjugg (792)

  I've tried before to move some business logic into the database because I thought it should be there. I got stuck figuring how to write the procedural language code. After fussing with it a bit, I pragmatically backed out, realizing the maintenance programmers were also strong in Perl, not procedual SQL programming. I rationalized that this decision made the application cheaper and easier to maintain, because a smaller skill set was involved. In this case, we still able to enforce some rules through the
• Re: Informal Survey on Databases (Score:1)

  by Adrian (66)

  1. How often have you ported an app from one database engine to another (e.g., MySQL to Oracle)?

  A fair number of times. Must be a dozen or so in the last 10 years. Once already this year and it's only February - and this was the second time that this particular application had it's database changed from underneath it.

  2. How often have you had completely separate apps writing to the same data store (using completely different code bases)?

  A significant minority of applications.

  3. Do you depend
• Answers ... (Score:2)

  by drhyde (1683)

  1. I often use SQLite for prototyping and then throw the prototype away and re-write in MySQL or Oracle. I've only once ported a working application from one db to another though, and that was Access to MS SQL Server.

  2. Whenever I have seperate applications writing to the database, they're pretty much always just seperate wrappers around a library - eg, a GUI front-end and a command-line front-end.

  3. I try not to use DB-specific features, at least in low-end databases like SQLite and MySQL, on the (alm