Database in Redhat Linux

I need decide which database going to run for Redhat Linux. I know MySQL is the most popular one in Linux world. I need you help me to fill out the blank and hole (?) in table below. Databases for Linux (Redhat) Y -- yes; N -- No; NA -- not apply; ? -- don't know/not sure Database Trigger/Store Procedure Transaction Foreign Key Constrain JDBC/RowSet C/C++ Library PerlDBI MySQL N N N N Y (mm.sql tyep 4) Y? Y Postgres Y? ? Y ? ? ? Informix Sybase Oracle DB2 I know Oracle, Sybase, Informix and DB2 support most or all of them in UNIX (Solaris, HP-UX, AIX, etc.) But I am not sure are they also support in Linux. Thank you very much if you can fill out the blanks and/or holes for me.

Freelancer wrote: > I need decide which database going to run for Redhat Linux. > I know MySQL is the most popular one in Linux world. I need > you help me to fill out the blank and hole (?) in table below. > > Databases for Linux (Redhat) > Y -- yes; N -- No; NA -- not apply; ? -- don't know/not sure > Database Trigger/Store Procedure Transaction Foreign Key Constrain JDBC/RowSet C/C++ Library PerlDBI Postgres Y Y Y N ?/? Y/N Y? Informix Y Y Y Y ? ? ? -- Martin Dressler e-mail: dr@musicabona.cz http://www.musicabona.com/

Here are the answers for DB2 on Linux: Trigger: Yes Store Procedure: Yes (choice of DB2 Stored Procedures Language, Java, C, C++) Transaction: Yes Foreign Key Constraint: Yes JDBC/RowSet: Yes C/C++ Library: Yes PerlDBI: Yes Freelancer wrote: > I need decide which database going to run for Redhat Linux. > I know MySQL is the most popular one in Linux world. I need > you help me to fill out the blank and hole (?) in table below. > > Databases for Linux (Redhat) > Y -- yes; N -- No; NA -- not apply; ? -- don't know/not sure > > Database Trigger/Store Procedure Transaction Foreign Key Constrain > JDBC/RowSet C/C++ Library PerlDBI > MySQL N N N > N Y (mm.sql tyep 4) > Y? Y > Postgres Y? ? Y > ? ? ? > > Informix > Sybase > Oracle > DB2 > > I know Oracle, Sybase, Informix and DB2 support most or all of them in > UNIX (Solaris, HP-UX, AIX, etc.) But I am > not sure are they also support in Linux. > Thank you very much if you can fill out the blanks and/or holes for me.

I need decide which database going to run for Redhat Linux. I know MySQL is the most popular one in Linux world. I need you help me to fill out the blank and hole (?) in table below. Databases for Linux (Redhat) Y -- yes; N -- No; NA -- not apply; ? -- don't know/not sure Database Trigger/Store Procedure Transaction Foreign Key Constrain JDBC/RowSet C/C++ Library PerlDBI MySQL N N N N Y (mm.sql tyep 4) Y? Y Postgres Y? ? Y ? ? ? ? Informix Sybase Oracle DB2 Else? I know Oracle, Sybase, Informix and DB2 support most or all of them in UNIX (Solaris, HP-UX, AIX, etc.) But I am not sure are they also support in Linux. Thank you very much if you can fill out the blanks and/or holes for me.

In comp.os.linux.misc Freelancer <someone@somewhere.world> wrote: : I need decide which database going to run for Redhat Linux. : I know MySQL is the most popular one in Linux world. I need : you help me to fill out the blank and hole (?) in table below. Its a pity for Linux World, that most hype is done by people who don't know what real database is. So they promote mySQL which is no more than fast flat-file search engine with SQL-like syntax. It cannot be considered real SQL just becouse SQL stands for Structured Query language, and mySQL doesn't support structured, i.e. nested queries. But database is much more than just search engine. It also should ensure integrity of data both by enforcing some conditions of them (i.e. foreign keys and triggers) and by rolling failed transactio back to consistent state. So, only free database is PostgreSQL. But PostgreSQL start to resemble real database only since 7.0 version, becouse before there was no foreign keys. I would consider that it IS a database, not RESEMBLES one only when it begin to support outer joins and binary large objects. Both are scheduled for 7.1. BTW, Inprise/Borland recently have open sources for Interbase, which IS the database. : I know Oracle, Sybase, Informix and DB2 support most or all of them in : UNIX (Solaris, HP-UX, AIX, etc.) But I am : not sure are they also support in Linux. All ones you've mention are supported. -- It's hard to tune heavily tuned code. :-) -- Larry Wall in <199801141725.JAA07555@wall.org>

If you want the Oracle features like Triggers/Stored Procedures, Integrity/Foreign Key Constraints, Transactions, Outer Joins, JDBC/ODBC Drivers, C/C++ Pre-Processor for Embedded SQL, Perl and Python Access and many more for the price of PostqreSql (i.e. FREE) look no further than SAP DB. SAP recently released its RDBMS in open source. Check http://www.sap.com/solutions/technology/sapdb/ Here is an extract of SAP site SAP DB is an open, SQL-based, relational database management system that provides high availability and performance scaling from small to very large implementations. In addition, SAP DB goes beyond relational database technology by offering object orientation as well as support for managing unstructured data. It supports open standards including SQL, JDBC and ODBC; access from Perl and Python; and HTTP-based services with HTML or XML content. SAP DB is platform independent, so users can deploy it for a wide array of projects. Since 1994, the SAP e-Business Solution is available on SAP DB technology. Today SAP DB is being used by nearly 800 customers. You may also want to go directly to the FAQ page http://www.sap.com/solutions/technology/sapdb/ I have no interest in the SAP company but when such a major company decides to release such a great piece of software in open source, I believe the Linux community should support them. Xavier Neys. PS: 800 SAP customers mean thousands of users :-) PPS: I am a newbie to Linux but have years of experience with Oracle/Unix. I still need to get my linux box up and running, than test this SAP DB and compare it with Oracle. This explains why I posted this with Outlook. Please forgive me :-) "Freelancer" <rhchui@yahoo.com> wrote in message news:3A1D1FFB.66953809@yahoo.com... > I need decide which database going to run for Redhat Linux. > I know MySQL is the most popular one in Linux world. I need > you help me to fill out the blank and hole (?) in table below. > > Databases for Linux (Redhat) > Y -- yes; N -- No; NA -- not apply; ? -- don't know/not sure > > Database Trigger/Store Procedure Transaction Foreign Key Constrain > JDBC/RowSet C/C++ Library PerlDBI > MySQL N N N > N Y (mm.sql tyep 4) > Y? Y > Postgres Y? ? Y > ? ? > ? ? > Informix > Sybase > Oracle > DB2 > Else? > > I know Oracle, Sybase, Informix and DB2 support most or all of them in > UNIX (Solaris, HP-UX, AIX, etc.) But I am not sure are they also support > in Linux. > Thank you very much if you can fill out the blanks and/or holes for me. > > >

In article <8vmgld$om4$1@wagner.wagner.home>, Victor Wagner <vitus@wagner.rinet.ru> writes >In comp.os.linux.misc Freelancer <someone@somewhere.world> wrote: >: I need decide which database going to run for Redhat Linux. >: I know MySQL is the most popular one in Linux world. I need >: you help me to fill out the blank and hole (?) in table below. > >Its a pity for Linux World, that most hype is done by people who don't >know what real database is. So they promote mySQL which is no more than >fast flat-file search engine with SQL-like syntax. And it's a real pity that there are so many people who think that the only valid type of database is a SQL database. > >It cannot be considered real SQL just becouse SQL stands for >Structured Query language, and mySQL doesn't support structured, i.e. >nested queries. By that argument *NO* database is "real SQL", because SQL is not a datastore - it is a *language* used by the client to talk to the back end. > >But database is much more than just search engine. It also should ensure >integrity of data both by enforcing some conditions of them (i.e. >foreign keys and triggers) and by rolling failed transactio back to >consistent state. And to me, a database is a complete environment, aka AS/400, Pick, etc. A SQL back-end is to databases what the rear legs are to pantomime donkey - it can stand on its own but is useless without the other half. > >So, only free database is PostgreSQL. But PostgreSQL start to >resemble real database only since 7.0 version, becouse before there was >no foreign keys. I would consider that it IS a database, not RESEMBLES >one only when it begin to support outer joins and binary large objects. >Both are scheduled for 7.1. > I think you mean the only free *relational* database - which is not the same thing at all. There are much better databases out there. While I would strongly suggest that all database programmers should know relational theory (it helps design immensely), there are a load of far better databases out there. SQL and relational databases put theoretical purity above practicality and functionality, which is why Oracle is such a beast - I could probably write programs that run faster, do more, and handle larger datasets, and all on a system half the size! just because I don't believe "relational is best". -- Anthony W. Youngman - wol at thewolery dot demon dot co dot uk Witches are curious by definition and inquisitive by nature. She moved in. "Let me through. I'm a nosey person.", she said, employing both elbows. Maskerade : (c) 1995 Terry Pratchett

In comp.os.linux.misc Anthony W. Youngman <thewolery@nospam.demon.co.uk> wrote: : In article <8vmgld$om4$1@wagner.wagner.home>, Victor Wagner : <vitus@wagner.rinet.ru> writes :>In comp.os.linux.misc Freelancer <someone@somewhere.world> wrote: :>: I need decide which database going to run for Redhat Linux. :>: I know MySQL is the most popular one in Linux world. I need :>: you help me to fill out the blank and hole (?) in table below. :> :>Its a pity for Linux World, that most hype is done by people who don't :>know what real database is. So they promote mySQL which is no more than :>fast flat-file search engine with SQL-like syntax. : And it's a real pity that there are so many people who think that the : only valid type of database is a SQL database. Sincerely, I never seen any other kind of database which is usable without writing special program for any query. SQL is only practical solution've seen, which allows you to type queries in interactively. There is also QBE, but it doesn't count, becouse it is a) relational b) if fully implementted is functionally equivalent to SQL. :>It cannot be considered real SQL just becouse SQL stands for :>Structured Query language, and mySQL doesn't support structured, i.e. :>nested queries. : By that argument *NO* database is "real SQL", because SQL is not a : datastore - it is a *language* used by the client to talk to the back : end. by this argument each relational database implements some subset of SQL+some extension to it. Even Oracle doesn't do ANSI 92 fully. Restriction which mySQL places on the programmers are worst of all - they causes them to PROGRAM, instead of to DESIGN. :> :>But database is much more than just search engine. It also should ensure :>integrity of data both by enforcing some conditions of them (i.e. :>foreign keys and triggers) and by rolling failed transactio back to :>consistent state. : And to me, a database is a complete environment, aka AS/400, Pick, etc. : A SQL back-end is to databases what the rear legs are to pantomime : donkey - it can stand on its own but is useless without the other half. SQL + storage manager behind them. Nothing more. Even OS is not always neccessary. May be FORTRAN preprocessor. Clients should be written on normal using jdbc, odbc, dbi or some other kind of standartized interface. Of course good interactive shell is good, but I always have dbish. :> :>So, only free database is PostgreSQL. But PostgreSQL start to :>resemble real database only since 7.0 version, becouse before there was :>no foreign keys. I would consider that it IS a database, not RESEMBLES :>one only when it begin to support outer joins and binary large objects. :>Both are scheduled for 7.1. :> : I think you mean the only free *relational* database - which is not the : same thing at all. There are much better databases out there. While I Please name _free_ non-relational database which is comparable with commercial ones. As far as I know, most free non-relational things are compared with say Adabas, like mySQL to Oracle or worse. : would strongly suggest that all database programmers should know : relational theory (it helps design immensely), there are a load of far : better databases out there. SQL and relational databases put theoretical : purity above practicality and functionality, which is why Oracle is such : a beast - I could probably write programs that run faster, do more, and : handle larger datasets, and all on a system half the size! just because : I don't believe "relational is best". Guys who wrote mySQL think same way. Unfortunately, they was wrong. Becouse there is nothing more practical then good theory. Theoretical purity gives flexibility, scalability and tunability. This is why people don't write on CODASIL anymore. : -- : Anthony W. Youngman - wol at thewolery dot demon dot co dot uk : Witches are curious by definition and inquisitive by nature. She moved in. "Let : me through. I'm a nosey person.", she said, employing both elbows. : Maskerade : (c) 1995 Terry Pratchett -- There ain't nothin' in this world that's worth being a snot over. -- Larry Wall in <1992Aug19.041614.6963@netlabs.com>

In article <904rq3$54b$1@wagner.wagner.home>, Victor Wagner <vitus@wagner.rinet.ru> writes >In comp.os.linux.misc Anthony W. Youngman <thewolery@nospam.demon.co.uk> wrote: >: In article <8vmgld$om4$1@wagner.wagner.home>, Victor Wagner >: <vitus@wagner.rinet.ru> writes >:>In comp.os.linux.misc Freelancer <someone@somewhere.world> wrote: >:>: I need decide which database going to run for Redhat Linux. >:>: I know MySQL is the most popular one in Linux world. I need >:>: you help me to fill out the blank and hole (?) in table below. >:> >:>Its a pity for Linux World, that most hype is done by people who don't >:>know what real database is. So they promote mySQL which is no more than >:>fast flat-file search engine with SQL-like syntax. > >: And it's a real pity that there are so many people who think that the >: only valid type of database is a SQL database. > >Sincerely, I never seen any other kind of database which is usable >without writing special program for any query. SQL is only practical >solution've seen, which allows you to type queries in interactively. >There is also QBE, but it doesn't count, becouse it is >a) relational >b) if fully implementted is functionally equivalent to SQL. > Ask an END USER to run a query over four entities. Oh, by the way, there's a many-to-many relationship in there somewhere... Dead easy for us, unless you assume the user is an idiot and stick a GUI in the way - unfortunately that's usually a self-fulfilling prophecy :-( > >Restriction which mySQL places on the programmers are worst of all - they >causes them to PROGRAM, instead of to DESIGN. > I don't know mySQL that well, but you need some programming for anything. If you mean triggers, data integrity etc, I gather mySQL was designed for fast extraction, and it sounds like you're using the wrong tool for the job... > > >:> >:>But database is much more than just search engine. It also should ensure >:>integrity of data both by enforcing some conditions of them (i.e. >:>foreign keys and triggers) and by rolling failed transactio back to >:>consistent state. > >: And to me, a database is a complete environment, aka AS/400, Pick, etc. >: A SQL back-end is to databases what the rear legs are to pantomime >: donkey - it can stand on its own but is useless without the other half. > >SQL + storage manager behind them. Nothing more. Even OS is not always >neccessary. >May be FORTRAN >preprocessor. Clients should be written on normal using >jdbc, odbc, dbi or some other kind of standartized interface. > >Of course good interactive shell is good, but I always have dbish. > A good interactive shell makes life easy... >:> >:>So, only free database is PostgreSQL. But PostgreSQL start to >:>resemble real database only since 7.0 version, becouse before there was >:>no foreign keys. I would consider that it IS a database, not RESEMBLES >:>one only when it begin to support outer joins and binary large objects. >:>Both are scheduled for 7.1. >:> >: I think you mean the only free *relational* database - which is not the >: same thing at all. There are much better databases out there. While I > >Please name _free_ non-relational database which is comparable with >commercial ones. As far as I know, most free non-relational things are >compared with say Adabas, like mySQL to Oracle or worse. I don't know of any _free_ ones that are currently usable. I'm working on MaVerick... > >: would strongly suggest that all database programmers should know >: relational theory (it helps design immensely), there are a load of far >: better databases out there. SQL and relational databases put theoretical >: purity above practicality and functionality, which is why Oracle is such >: a beast - I could probably write programs that run faster, do more, and >: handle larger datasets, and all on a system half the size! just because >: I don't believe "relational is best". > >Guys who wrote mySQL think same way. Unfortunately, they was wrong. >Becouse there is nothing more practical then good theory. > >Theoretical purity gives flexibility, scalability and tunability. >This is why people don't write on CODASIL anymore. > Rules are for the guidance of wise men, and the obedience of fools. The real world is not amenable to forcing into a relational mould. For some things it works fine, but trying to force non-relational data into a relational straitjacket can (will?) make life difficult later on. Why are people now throwing so much effort at object databases? Try running a data warehouse on a relational db - a big warehouse will bring a Cray to its knees... That's why I said I could blow Oracle into a cocked hat - I take their strengths, add them to mine, and dodge their straitjacket :-) -- Anthony W. Youngman <pixie@thewolery.demon.co.uk> 'Yings, yow graley yin! Suz ae rikt dheu,' said the blue man, taking the thimble. 'What *is* he?' said Magrat. 'They're gnomes,' said Nanny. The man lowered the thimble. 'Pictsies!' Carpe Jugulum, Terry Pratchett 1998 Visit the MaVerick web-site - <http://www.maverick-dbms.org>; Open Source Pick

In comp.os.linux.misc Anthony W. Youngman <thewolery@nospam.demon.co.uk> wrote: :>: And it's a real pity that there are so many people who think that the :>: only valid type of database is a SQL database. :> :>Sincerely, I never seen any other kind of database which is usable :>without writing special program for any query. SQL is only practical :>solution've seen, which allows you to type queries in interactively. :>There is also QBE, but it doesn't count, becouse it is :>a) relational :>b) if fully implementted is functionally equivalent to SQL. :> : Ask an END USER to run a query over four entities. Oh, by the way, : there's a many-to-many relationship in there somewhere... Using QBE? Just easy - draw a line by mouse here, there and elsewhere and you've four entities linked together. Using SQL? a bit more difficult. You have to tell stupid machine that value of TYPE_ID is this table should be equal to TYPE_ID in that table, but tell on almost plain English. :>Restriction which mySQL places on the programmers are worst of all - they :>causes them to PROGRAM, instead of to DESIGN. :> : I don't know mySQL that well, but you need some programming for : anything. If you mean triggers, data integrity etc, I gather mySQL was : designed for fast extraction, and it sounds like you're using the wrong : tool for the job... I don't use it, and probably never would. Becouse I cannot imagine a problem which wouldn't benefit from good decomposition. If it is tabular by nature, it would need something more relational than mySQL. If not, it is better to use something ENTIRELY different. Even if it is not possible to decompose tables, program might benefit from distributing data between different schemas with different access rights and grant appropriate permission. Oracle allows to access different schemas from same connection, mySQL doesn't. And if you have about 50 simulateously connected copies of Apache (not mention interactive applications) mySQL begins to crawl. :>SQL + storage manager behind them. Nothing more. Even OS is not always :>neccessary. :>May be FORTRAN :>preprocessor. Clients should be written on normal using :>jdbc, odbc, dbi or some other kind of standartized interface. :> :>Of course good interactive shell is good, but I always have dbish. :> : A good interactive shell makes life easy... Of course. And in this field psql is much better than sqlplus. May be I should find time to write "GNU Oracle Shell" - something which is distributed OpenSource and uses GNU readline, but works with Oracle database. :>:>So, only free database is PostgreSQL. But PostgreSQL start to :>:> :>: I think you mean the only free *relational* database - which is not the :>: same thing at all. There are much better databases out there. While I :> :>Please name _free_ non-relational database which is comparable with :>commercial ones. As far as I know, most free non-relational things are :>compared with say Adabas, like mySQL to Oracle or worse. : I don't know of any _free_ ones that are currently usable. I'm working : on MaVerick... So, we are back to my point - PostgreSQL is only free database. It is relational (what's pity), but no non-relational one exists. :>Guys who wrote mySQL think same way. Unfortunately, they was wrong. :>Becouse there is nothing more practical then good theory. :> :>Theoretical purity gives flexibility, scalability and tunability. :>This is why people don't write on CODASIL anymore. :> : Rules are for the guidance of wise men, and the obedience of fools. The : real world is not amenable to forcing into a relational mould. For some : things it works fine, but trying to force non-relational data into a : relational straitjacket can (will?) make life difficult later on. Why Of course. But it only means that somebody picks wrong theory. And if you want something better, you'll have to find branch of mathematics which describe your problem better than relational algebra. Probably, I've found one for my problem. Now some people from MSU work by the contract with our firm on the graph-based database. : are people now throwing so much effort at object databases? Try running : a data warehouse on a relational db - a big warehouse will bring a Cray : to its knees... It seems that objects is an universal solution for problems where no special theory exists. That is why all OO languages are so bloated. -- Randal can write one-liners again. Everyone is happy, and peace spreads over the whole Earth. -- Larry Wall in <199705101952.MAA00756@wall.org>

Anthony W. Youngman wrote in message ... >In article <904rq3$54b$1@wagner.wagner.home>, Victor Wagner > >Rules are for the guidance of wise men, and the obedience of fools. The >real world is not amenable to forcing into a relational mould. For some >things it works fine, but trying to force non-relational data into a >relational straitjacket can (will?) make life difficult later on. Why >are people now throwing so much effort at object databases? Try running >a data warehouse on a relational db - a big warehouse will bring a Cray >to its knees... Hmmmm - I thought object databases were the ultimate expression of relational theory. What are references if not joins into other "tables"? What's the point of storing multiple objects with references except another manifestation of highly normalised data? The only difference is that the data types stored are more modern - in the sense that we are no longer constrained to storing chars and integers, but we are allowed to store entire objects as first class column members. An object containing a list is now no longer considered "un-normalised" because that list can now be treated as a non-divisible atom, a living entity in itself. If you insist that a list should be divided, then perhaps we should also break down all our char(10) into (upto 10) records of char(1) which we glue together? I'm afraid object databases tend to PROVE the acceptance of the relational model. I'm not too impressed with a big fat hugely parallel number-crunching processor (Cray) being asked to perform database duties. Not a very impressive box I'm afraid. I can't see how several thousand parallel floating point accumulators can help a database engine of any kind. Or have Cray started developing machines with highly parallel I/O systems tuned for database activity, letting number crunching fall away as an unimportant market?