Subject | Re: [ib-support] Two things Firebird needs for corp acceptance |
---|---|
Author | Todd Brasseur |
Post date | 2002-06-10T17:00:45Z |
Agreed,
When dealing with an Open Source database (virtually free) we can't
expect everything right now. We either have to put in the work to add
it (which I don't have the time or ability to do) or wait or move to a
different database that has more capabilities.
Ever since building our application we have struggled with our choice of
database. We love Firebird. It does most everything we need and what
it can't do we have built work arounds. Our problem is that when we go
to sell our application, everyone wants SQL Server or Oracle. Some of
our current clients love our application but their IT people want us to
change to SQL Server. We have many small clients who don't care about
the database and don't want to have to pay for a database. They only
pay a couple of thousand dollars a year in support. They don't want to
pay another thousand for a database. What to do ... what to do ....?????
Right now I think eventually we will have to change to SQL Server. I'm
sure not looking forward to re-writing the database included 120 tables,
four hundred stored procedures and many many triggers.
My two cents.
Todd
Artur Anjos wrote:
When dealing with an Open Source database (virtually free) we can't
expect everything right now. We either have to put in the work to add
it (which I don't have the time or ability to do) or wait or move to a
different database that has more capabilities.
Ever since building our application we have struggled with our choice of
database. We love Firebird. It does most everything we need and what
it can't do we have built work arounds. Our problem is that when we go
to sell our application, everyone wants SQL Server or Oracle. Some of
our current clients love our application but their IT people want us to
change to SQL Server. We have many small clients who don't care about
the database and don't want to have to pay for a database. They only
pay a couple of thousand dollars a year in support. They don't want to
pay another thousand for a database. What to do ... what to do ....?????
Right now I think eventually we will have to change to SQL Server. I'm
sure not looking forward to re-writing the database included 120 tables,
four hundred stored procedures and many many triggers.
My two cents.
Todd
Artur Anjos wrote:
>
> Todd:
>
> I agree with you. There are some appl that could benefit from both
> situations.
>
> What I don't agree is that this 2 things will keep 'corp developers' away
> from using Firebird.
>
> As you can see in 'Open Features' request:
>
> -------------
> 451924 Temporary tables Feature request
> Allow for the definition of temporary tables which are only visible within
> the current connection context and which are deleted upon connection
> disconnect/lost.
> -------------
> 446244 Multi-database access in triggers and SP Feature request
> Allow for other databases to be accessed from within triggers and SPs.
> ---------------
>
> Personally, I think that feature request 451912, 446233, 446232 just to
> mention a few ones, are more important than the 2 features in discussion
> here. What I think we are discussing here it's not if a feature it's
> good or
> not, but priorities to implement that features in Firebird.
>
> Artur
>
> ----- Original Message -----
> From: "Todd Brasseur" <todd.compass@...>
> To: <ib-support@yahoogroups.com>
> Sent: Monday, June 10, 2002 4:57 PM
> Subject: Re: [ib-support] Two things Firebird needs for corp acceptance
>
>
> >
> >
> > Artur Anjos wrote:
> >
> > > Tony,
> > >
> > > I will complete Martjin questions with this one:
> > >
> > > - Why you are joining 'corp developer' with 'corp client'?
> > >
> > > As Martjin, I don't know what's the problem to have lots of tables in
> the
> > > same DB.
> >
> >
> > I would like to be able to join databases as well. We have an
> > application that stores alot of data that changes all the time. It also
> > stores alot of images which hardly ever change. We split up the
> > database into 2 separate databases for a few reasons:
> >
> > 1) The images are huge (several gigabytes). They only need to be
> > backed up once a month or so.
> > 2) The user likes to make local copies of the database to do analysis.
> > It makes it alot easier to only have to backup and restore 150 megs
> > rather than 10 gigs.
> >
> >
> > Also, we are trying to integrate with some other data that isn't part of
> > our application. With SQL Server our clients can add triggers, etc.
> > that do things between databases. We can't do that.
> >
> > > You can do almost all things that you want in a SP without using a
> > > temporary
> > > table. Also, it's very easy to emulate a temporary table with a table
> > > and an
> > > ID, in most part of the jobs you need a temp table to.
> >
> > Temporary tables would be great for complex calculations. We select a
> > ton of data and then need to calculate math on the data. It would be
> > nice to store the results of one query either in an array or a temporary
> > table and then be able to calculate standard deviations, medians etc.
> >
> > Todd
> >
>
>
>
> To unsubscribe from this group, send an email to:
> ib-support-unsubscribe@egroups.com
>
>
>
> Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service
> <http://docs.yahoo.com/info/terms/> .