Forgot your password?
typodupeerror
Databases Programming Software IT Linux

Sybase Releases Free Enterprise Database on Linux 386

Posted by CowboyNeal
from the everyone's-favorite-price dept.
Tassach writes "Sybase announced today that they are releasing a free (as in beer) version of their flagship database for Linux. The free version is limited to 1 CPU, 2GB of RAM, and 5GB of data, which is more than adequate for all but the most demanding applications. This release provides a very attractive alternative to Microsoft SQL Server, and gives developers and DBAs an extremely powerful argument to use against the adoption of Microsoft-based solutions. For those who are unfamiliar with the product, Microsoft's version of Transact-SQL is nearly identical to Sybases's. This high degree of similarity makes porting applications between the two platforms very easy. Sybase is supported by numerous open-source projects, including sqsh (SQL shell), FreeTDS, and SybPerl."
This discussion has been archived. No new comments can be posted.

Sybase Releases Free Enterprise Database on Linux

Comments Filter:
  • by dotgain (630123) on Thursday September 09, 2004 @05:49AM (#10198861) Homepage Journal
    While MS SQL Server is not free, MSDE, the MS Database Engine is.
  • Re:Smart move (Score:2, Informative)

    by Anonymous Coward on Thursday September 09, 2004 @05:53AM (#10198879)
    As far as I know, MS SQL Server was originally based on Sybase, hence the similarity in T-SQL. Some time ago Sybase used to make the latest-1 major release for free under Linux, if I am not mistaken.
    They stopped that and are coming up with this now... At least interesting as an alternative to MSDE which is also limited concerning concurrent connections and size.
  • by natslovR (530503) on Thursday September 09, 2004 @05:54AM (#10198885)
    It can only be used internally, so you can't use it in situations where you may have been able to get away with the hardware restrictions on a small external site or (i guess) distributed to clients as part of your product.
    1. USE OF PROGRAMS. You may install and use the Programs solely for your internal business purposes by your employees, agents and contractors. The Programs may not be transferred, distributed, sold, assigned, sublicensed or otherwise conveyed (whether by operation of law or otherwise) to another party without Sybase's prior written consent.
  • by Anonymous Coward on Thursday September 09, 2004 @06:06AM (#10198926)
    Mr. Goatse is back with a vengance...
  • PARENT is a TROLL! (Score:2, Informative)

    by Anonymous Coward on Thursday September 09, 2004 @06:09AM (#10198934)
    Don't click this link! It's a porn shock site!

    Who modded this up?
  • Re:Smart move (Score:5, Informative)

    by popeyethesailor (325796) on Thursday September 09, 2004 @06:13AM (#10198947)
    That company from Redmond, bought the tech from Sybase; the toy database you didnt mention is certainly capable, and is more than adequate for small-medium sites. Unless you meant Access.

    And Oracle is already the 'Oracle' of linux, it was among the first enterprise DBs available, and lots of Oracle internal sites already run on RHEL.

    This move by Sybase is mostly just a tease- you would probably need to buy a license if you need anything that requires Sybase's capabilities.
    Even Oracle will mail you a full devkit, with the enterprise DB+all the goodies. However I cant imagine anyone using this in Production boxes.

    Sybase has a nice niche among banks and some large datawarehouse-type environments. It is an order of magnitude easier if you're from an Oracle-Db2 background.

  • by MartinG (52587) on Thursday September 09, 2004 @06:17AM (#10198958) Homepage Journal
    see comment
  • Good news (Score:3, Informative)

    by the_dubstyler (810220) on Thursday September 09, 2004 @06:17AM (#10198960)
    This is, IMHO, a very good thing. Sybase is an excellent DB (I've worked with some top developers who swear by it) and a much better option than MsSQL for small projects where 1 proc/5Gb is more than enough (and there are lots of projects like that). Considering that no client I've ever worked with has been willing to go for PostgresSQL/MySQL (preferring MsSQL), this will be a welcome victory against Microsoft, as Sybase has a pretty good name in the db game.
  • by azaris (699901) on Thursday September 09, 2004 @06:18AM (#10198961) Journal

    You are missing the point. It makes it easy to convert from Microsoft SQL. Imagine thousands of independent software developers with an alternative to MSQL within easy reach. Their entire solution cost is now reduced, and they will sell better. At least the ones that take the chance.

    I'm not sure so many independent software developers use MS SQL anyway, but there has for a while been a light version of MS SQL, MSDE, available for a free download [asp.net], with most of the features of MS SQL but with similar restrictions to this Sybase offering.

    But this appears to be targeted mostly at Linux developers so it's competition for PostgreSQL and the Abomination That Shall Not Be Named.

  • by RahoulB (178873) on Thursday September 09, 2004 @06:23AM (#10198968) Homepage
    depends who you are selling to ... my company sells to a few (UK) local government authorities and SQL Server is a "tick in a box" on their checklists. Sybase currently isn't, but being a "brand name" will probably help it there.
    Postgres doesn't even come into the equation
  • by bani (467531) on Thursday September 09, 2004 @06:24AM (#10198972)
    ...that microsoft sql server is sybase [wikipedia.org] (albeit 1993 codebase)
  • by blowdart (31458) on Thursday September 09, 2004 @06:32AM (#10198986) Homepage
    Not really. MS SQL used to be Sybase, and thus TSQL used to match. But since 6.5 Microsoft made SQL Server their own, changed the engine to be more ANSI SQL 92 Compliant (ANSI joins in Oracle? Hah), and now as SQL2005 comes over the horizon they've added more compliance with later SQL standards (although nowhere near fully compliant).

    If you're expecting to take a recent Microsoft database script and run it on Sybase without any problems you're dreaming.

  • by conejoloco (811948) on Thursday September 09, 2004 @06:33AM (#10198988)
    I have worked with both a few years ago (migration from Postgres 6 to Sybase 11) and sybase performance was outstanding, compared to Postgresql.
    I hope postgresql performs better now.

    Moreover, this is not the first time Sybase makes this offer : Sybase for Linux 11.0.3 was free to use on Linux, with no limitation.

    I personnaly used it for my Web shop, as this database is not only fast and secure, but also quite easy to program with ( especially compared to Oracle ).

    The only drawback of Sybase is the lack of standard administration Tools. You have to use a product like (overpriced and windows-only) Emabarcadero DBArtisan.
  • Re:Front End...? (Score:4, Informative)

    by m4k3r (777443) on Thursday September 09, 2004 @06:37AM (#10199001)
    It certainly does!

    Plus, without ever using Sybase (I'm more of a PostgreSQL fan), I'm fairly sure that Sybase would provide a C/C++ api.

    (For those that haven't caught on, Sybase is a competitor to such products as Oracle, DB2, PostgreSQL etc, and is not compareable to silly little toys such as MS Access)

  • by popeyethesailor (325796) on Thursday September 09, 2004 @06:54AM (#10199044)
    You can already download for free, Oracle for Linux,Windows and a few more platforms. All you need is an OTN membership. However its only for Non-production use i.e. you cant run your business off it.

    As for Open-sourcing the DB engine, you can keep dreaming though..
  • by Gaewyn L Knight (16566) <vaewynNO@SPAMwwwrogue.com> on Thursday September 09, 2004 @07:06AM (#10199064) Homepage Journal
    Ah yes... but what if you are stuck on an application that you don't have access to the codebase? With this "most" ms-sql or Sybase SQLAnywhere applications can simply be told where the new datastore is and work.

    We hae several POS and ERP applications on our campus that have been locked into MS-SQL or SQLAnywhere (bleh!). Yesterday after downloading sybase and getting it installed I was able to transfer and fire up test instances of 7 of the 9 applications without ever needing to ask the company that wrote it to make any changes for me.

    Would I prefer these apps be FOSS... YES! We are slowly writing new versions as we get time... but it takes time and this gives us a way to save money now.
  • by tjwhaynes (114792) on Thursday September 09, 2004 @07:38AM (#10199146)

    I fact, I've been waiting for free-download Oracle/DB2 "personal database" or some limited opensource release of Oracle/DB2 for a while.

    So, err, maybe you wanted this?

    DB2 UDB Personal Developer Edition [ibm.com]

    Cheers,
    Toby Haynes

  • by kiwimate (458274) on Thursday September 09, 2004 @07:47AM (#10199186) Journal
    Right! Here's something else to consider...in the past, when you had an application people might want to evaluate before they committed time and money to buying the full product, what did you do if it required a database and you were concerned your clients may not have an existing database implementation? Exactly...you included the free MSDE engine so people didn't have to go out and spend money on MS SQL or Oracle for what was only an evaluation. If it worked out well and the customer bought the software, they now had a database which, if MSDE wasn't up to snuff for a full production deployment, could be painlessly migrated to MS SQL. The engine is exactly the same, so no translation is necessary.

    This worked out so well, precisely because MSDE was free to redistribute and easy to migrate to MS SQL, that MSDE is now included with thousands of applications. And remember -- if you ever outgrow its limitations, it can be directly moved over to MS SQL.

    Coincidentally, MS SQL (which, as everyone is ecstatic to be able to point out, used to be Sybase) continues to gain market share. Sybase (see above) does not.

    The big three at the moment in terms of market share [technewsworld.com] are Oracle, IBM, and Microsoft. Oracle is #1 but is slowly losing market share to IBM and MS. Sybase is #4 -- but that #4 translates to 3.6%. And it's static -- they're not gaining any of that market share being lost by Oracle.
  • by laird (2705) <lairdp@nOSPAm.gmail.com> on Thursday September 09, 2004 @08:01AM (#10199231) Journal
    "It can only be used internally, so you can't use it in situations where you may have been able to get away with the hardware restrictions on a small external site or (i guess) distributed to clients as part of your product."

    This same sort of restriction is fairly common in the "enterprise software" space. All it really means is that you can't bundle the free version invisibly into your application (which is OK), and you can't resell "used software" (which kinda sucks).

    This means that your customers have to get their own (free) copy from the primary vendor. Oracle, Sybase, MS, etc., all do this, because they want to have a direct relationship with all of their customers so that they can support them.

    The "no reselling" part of the deal is a bummer, though. For example, I worked at a startup that bought a $180K Oracle license, and when the company went the way of most startups (sigh), this provision meant that the Oracle license couldn't be sold to get back some money for the investors. Of course, vendors never approve reselling the license, because they'd rather sell a new license to the buyer.
  • Express Edition (Score:2, Informative)

    by DJ-Dodger (169589) on Thursday September 09, 2004 @08:13AM (#10199273) Homepage
    Sounds an awful lot like Microsoft's new free version of SQL Server [microsoft.com], SQL Server 2005 Express Edition, currently in Beta. Almost exactly like full-blown SQL Server, but only supports 1 CPU, 1GB of RAM and 4GB DB size.
  • Re:Dual core chips ? (Score:5, Informative)

    by mpeppler (128232) on Thursday September 09, 2004 @08:19AM (#10199301)
    You can use this version of Sybase on a machine with any number of CPUs. The issue is that you can't configure it to use more than one CPU at a time (i.e. you can only configure one engine).

    Michael

  • Re:Too risky... (Score:1, Informative)

    by Anonymous Coward on Thursday September 09, 2004 @08:30AM (#10199351)
    Please, good sir, enlighten us as to the reasons for using such databases.

    There are a few advantages that the expensive heavy hitters have over their Free counterparts. (I'm not a DB developer, but I'll do my best to illustrate...) Three of the most commonly cited are:

    1) Transaction support: when complex operations are modeled as a single "transaction", the data tables are locked in such a way that either all of the data get updated, or none of them do. Prevents data corruption if the system should go down while an complex operation is in progress, because the individual operations within a transaction are completed together or not at all.

    2) Replication: multiple databases, on-line or off-line, copying data to each other in real time or at periodic intervals. This allows you to load-balance between a number of database servers and/or maintain a hot spare backup, because you can keep them synchronized at intervals of whatever granularity is needed.

    3) Scaling: the big boys often scale better to run on 16-way+ systems with huge terabyte-size datasets. Oracle, for example, routinely deploys onto machines like that. This is probably the most important differentiator.

    As far as transactions and replication go, the Free alternatives often have support for them, but it's usually not as robust as that of the expensive ones. The thing is, most companies who buy these $50,000 databases don't really require them and would be fine with, for example, Postgres instead. Well, that's my $.02 .

    -Dave
  • by wackysootroom (243310) on Thursday September 09, 2004 @08:33AM (#10199361)
    Postgres is much faster now than it was in the 6.x days. Back then it had a (deserved) reputation for being slow. There were many speed enhancements put into place before 7.x was released.

    Postgresql is still not quite as fast (in my experience) as MySQL, but the comparison is not fair due to MySQL's lack of features.

    I've read some benchmarks comparing oracle to postgresql and pgsql comes out close on most tests and beats oracle on a few. The benchmarks are gone, sadly, due to Oracle's "no benchmarking" clause in their EULA.
  • by BigGerman (541312) on Thursday September 09, 2004 @09:14AM (#10199609)
    >>so people didn't have to go out and spend money on MS SQL or Oracle for what was only an evaluation

    Just for the record, Oracle has always been available for free download in complete, unrestricted form. So for evaluation, people would just download and install it. Now, running production on unsupported and therefore unpatched Oracle instance - is the whole other matter.

  • by dasmegabyte (267018) <das@OHNOWHATSTHISdasmegabyte.org> on Thursday September 09, 2004 @09:23AM (#10199685) Homepage Journal
    Without problems, you're right. But the changes aren't that great. We do primary development on MS SQL Server (it's easier than Sybase, because Sybase doesn't tell you the syntax of the proc you just wrote is wrong or references non existant fields or tables until you RUN the script. MS has a pre-processor) and I'm the guy who makes sure things run on Sybase. Basically, I do all the compatibility work in a single Textpad Macro. It's actually sort of simple:

    1) Strip out the SET statements referencing ANSI_NULLS
    2) Convert Niladic function names (e.g. CURRENT_USER -> USER)
    3) Add Set DATE_FORMAT mdy, because the default in Sybase is ymd.
    4) Find strings unicode strings and strip off the N'
    5) Make sure all JOINS have their ON clause directly after themselves...MS lets you nest them, which I think makes for a better looking statement
    6) Make sure the retarded VB developer didn't declare all his variables "@foo AS Integer", illegal syntax with illegal datatypes that MS SQL Server would fix for you.
    7) Fix the IDENTITY syntax (basically, removing the step and start-at values) on CREATE TABLE
    8) Remove ADD CONSTRAINTS that are really defaults or primary keys, and move them to ALTER TABLE ADD DEFAULTs
    9) UNION ALL statements don't have column names during parsing in Sybase, so you can't do ORDER BY id_name, you have to do ORDER BY column_number. I think this is cleaner anyway, and it lets you change the name of the column more easily (can be important with ADO.NET, when mapping datasets)
    10) Table variables don't work so hot in Sybase. I just create temp tables with hashmark names, same idea with a little less performance.

    And I think that's it. Not that bad, really, and the script you end up with is comaptible with both MS SQL Server AND Sybase! I just finished a program that (unlike MS SQL Server) doesn't add crap like this to its scripts, thus making it trivial for us to port our apps back and forth.
  • My experience (Score:2, Informative)

    by FernandoN (802634) on Thursday September 09, 2004 @09:44AM (#10199888)
    Since I've used Sybase ASE 12.5 recently, I'd like to make Some considerations:

    -It is very sensitive about the OS configuration, only runs well on supported platforms (RH Enterprise, Suse, etc). If it finds anything not conforming its requirements, displays the annoying "Proccess is infected with 11" (meaning Segmentation faults).
    -CLI client totally crippled: the user has to type go after each command, no line-editing, no history, poor output formatting. Fortunately, sqsh, mentioned on parent, is a nice replacement.
    -ODBC driver for Unix/Linux not available for free.
    -Native C/C++ API, ctlibrary, implements a finite state machine, enforcing the programmer to ask twice if the result set is done.
    -Conversion to Transact-SQL data types from MySQL or Postgres is very tricky, because it doesn't have sub-integer types (smallint, mediumint, etc). Also, it uses different escape characters: eg. '' (two apostrophes) to represent one apostrophe inside a delimited string.

    From what I saw, it's not worth it migrating from MySQL or Postgres. If the migration is from MS SQL, though, it is a very interesting move, since the compatibility among the two is is still good.

  • by HancockDC (148897) on Thursday September 09, 2004 @09:46AM (#10199909) Homepage
    A couple points:
    1. Oracle and Sybase (and SQL Server and some of the open source databases) have their idiosyncratic way of doing joins but can handle ANSI joins as well. Supposedly if they do business with the Federal Government, they need to be ANSI92-compliant. I have take Sybase and Oracle DBA training (by the respective vendors) and they both concede that neither is fully compliant. (but they are "working on it")

    2. At my last DBA class I was asked why I would do ANSI joins when I could use the method supplied by the vendor. My answer was "code portability". The instructor sniffed and moved on. I won't tell which RDBMS vendor that was, but I doubt either Oracle or Sybase have much interest in encouraging portability.

    3. The last time I checked, Sybase's isql client could connect to a SQL Server backend and do transact-sql. The API is still pretty similar.

    4. Several years ago, Sybase made their ASE 11.0.3.3 server available for free and unrestricted use to users. No support, but you could run it in production mode with no licensing fees. Now it seems they are doing this again. with 12.5.2. Personally, I am thrilled, and wish Oracle and the others would follow suit.


    To reminisce a bit, I first started using Sybase when they were at version 4.8 and I was starting work with one of the fledgling genome database projects. They practically gave away licenses to such groups (80%) discount. They were known then, as now as a business-oriented RDBMS. They failed to continue in this vein, and the support costs started rising faster than our budgets. The Linux version cost less, and the annual maintenance was far less.

    In the meantime Oracle was very agressive in the higher education market, and still is. These two companies have a lot to offer, even if they aren't Open Source.

    A reason why a small company might want to go with a free version of a commercial enterprise level RDBMS might be found in the disaster recover features that each has. I am far more familiar with Sybase internals, having taken a course that told me more than I every wanted to know about how it keeps track of data. And I have also recovered data that otherwise might have been lost forever. Oracle's features are just as good, but I have not had the "pleasure" of testing them when the pucker factor is maxed out.

  • Re:Dual core chips ? (Score:1, Informative)

    by RallyXgen (768909) on Thursday September 09, 2004 @10:17AM (#10200171)
    Look it's really very simple. Each databases engine (read process) is capabale of running multiple threads (read connections/queries). In fact, each query can be split into multiple threads. So if I have 6 engines, I can run 6 threads concurrently. The idea being that an OS is generic and it created a virtual DB OS on top of your OS making 'better' choices that letting the OS choose which process gets CPU. So this engine binds very tightly to a CPU. In fact they work best when they don't share the CPU i.e. a dedicated DBMS server. So it is multithreaded but the process will bind to a CPU (this can be enforced on some OS).
  • Re:My experience (Score:4, Informative)

    by MattRog (527508) on Thursday September 09, 2004 @10:32AM (#10200370)
    It is very sensitive about the OS configuration, only runs well on supported platforms (RH Enterprise, Suse, etc). If it finds anything not conforming its requirements, displays the annoying "Proccess is infected with 11" (meaning Segmentation faults).


    ASE 12.5 runs just fine on plenty of Linux distros. We run it in production on Red Hat 7.2. It will NOT give "Infected with 11" errors simply because you're on a different (non-supported) distro; it gives you those errors if libraries are missing/not the right version.

    Conversion to Transact-SQL data types from MySQL or Postgres is very tricky, because it doesn't have sub-integer types (smallint, mediumint, etc)


    Are you on drugs? Not only are most of MySQL's datatypes against the SQL standard, but ASE supports:
    int (-2,147,483,648 and 2,147,483,647), inclusive.
    smallint (-32,768 and 32,767), inclusive.
    tinyint (0 and 255), inclusive

    Transact-SQL provides the smallint, int, numeric, and decimal SQL92 exact numeric datatypes. The tinyint type is a Transact-SQL extension.

    Also, it uses different escape characters: eg. '' (two apostrophes) to represent one apostrophe inside a delimited string.


    Blame MySQL and PostgreSQL for not correctly implementing the ANSI SQL STANDARD SPECIFICATION for escaping characters. This is the same as if you wanted to migrate to Oracle or Microsoft SQL Server, or any other product that correctly interprets this ANS SQL standard feature.
  • by GooberToo (74388) on Thursday September 09, 2004 @10:34AM (#10200389)
    Postgresql is still not quite as fast (in my experience) as MySQL, but the comparison is not fair due to MySQL's lack of features.

    Well, for single user experiences, MySQL probably is faster. PostgreSQL tends to scale much, much better than MySQL. In other words, if you have a DB where you expect to have lots of active users with a diverse set of concurrent activity (selects, updates, inserts, deletes), PostgreSQL traditionally zooms way ahead of MySQL. It's a question of how you expect to use your database.

    Basically, it's a myth that MySQL is faster than PostgreSQL. A myth, I might add, which MySQL themselves help propagate. Simple fact is, MySQL probably is faster in the developer's eyes. Once it's deployed, PostgreSQL is more than likely the faster of the two. Granted, there are some corner cases where MySQL is still faster than PostgreSQL, but those are the exceptions and NOT the rule.
  • Re:Dual core chips ? (Score:3, Informative)

    by mpeppler (128232) on Thursday September 09, 2004 @10:34AM (#10200393)
    No - of course Sybase is multi-threaded, and has been since day one (long before Oracle used threading).
    A multi-threaded app will only run on one CPU at a time, at least in most cases. What "engines" mean here is one or more engines that access the same set of shared memory. You usually configure engines based on the number of CPUs that are available, and each engine is multi-threaded.

    Michael

  • by scottsevertson (25582) on Thursday September 09, 2004 @11:00AM (#10200773) Homepage
    Sybase sucks. Then again, so does every other database product I've ever worked with (Oracle 7i-9i, MS SQL Server 6.5-2000, Informix, Postgres 7.1 - 8.0, *and* MySql). They all just suck in different ways.

    If you spend enough time with any product, you'll find little quirks that drive you insane. A couple off the top of my head for Sybase:

    1. Chained & Unchained modes. Sybase supports a SQL 92-compliant transactional mode, and a hacked up "autocommit" mode, with optional transactional support. The hacked up mode is default, and the SQL 92-compliant mode has some severe limitations.

    2. No DDL inside transactions. So what? That includes creating temporary tables. You want to call a stored proc from within a transaction? It better not touch the tempdb.

    3. Table-level locking by default. This one just blows me away; Sybase didn't support row-level locking until somwhere around version 11, and table-level locking is still the default. If you're DBAs aren't on top of things, you'll have deadlocks all over the place. They still haven't enabled it for the system tables, so make doubly sure you don't do any long-running code that touches them, or you'll have deadlocks for sure.

    If you think I'm bullshitting, check out a quasi-white paper (grey paper?) I posted a while ago to the iBATIS support forms - it's got a lot more detail about some of the problems, and some Java-based work-arounds: http://sourceforge.net/forum/message.php?msg_id=27 20775

    So, would I choose Sybase over the competition? Maybe about 3 years ago, before other DBs got decent replication support - that was one of their claims to fame. Performance doesn't seem to be that big of an issue - hardware is often cheaper than engineering around db limitations.

    If I had to rank what I've used in order of preference, it would be:

    1. Postgres
    Maybe because I've only used it for about 8 months, but Postgres has not *yet* disappointed me. Transaction support has been perfect, and no major performance problems. Then again, I haven't done any stored proc work, so maybe I should give it time.

    2. MS SQL Server
    I cringe to say this, but MS's developer tools push their DB up on my list. Query Analyzer has excellent "show plan" support, and their management tools are great. I'm generally pretty happy, although their JDBC driver could use some work, and DTS was pretty weak last time I used it.

    3. Oracle
    Cost knocks this one down a bit, and I'm a bit rusty as well. Last time I ran Oracle on Linux was shortly after it was released, and their install procedure was a *bitch*. However, nifty features like data partitioning were definitly worth the extra money.

    4. Sybase
    See above. It's decent, now it's free for small projects, but I'm annoyed.

    5. Informix
    I'm out of date on Informix, but I have bad memories, mostly of constantly overfilling the transaction logs, then having the DB stop working with an unclear error message. I understand the need for a DBA to monitor this on a production environment, but it was a pain in the ass in development.

    6. MySql
    OK, I'm going to get bashed on this one. The old limitations left a sour taste in my mouth, and too many critical features are brand new. I will reconsider, though, after it has a little more time to mature.

  • Uh... (Score:3, Informative)

    by IANAAC (692242) on Thursday September 09, 2004 @11:13AM (#10200985)
    I'm sure by now you realize they were talking about MS SQL, not MySQL, right?
  • Re:Dual core chips ? (Score:1, Informative)

    by Anonymous Coward on Thursday September 09, 2004 @11:16AM (#10201037)
    ASE does not use native/operating system threads -- it has its own threading model developed in the days when there weren't any OS threading models around. Sybase was way ahead of its time. It will perform concurrent requests just fine.
  • by chris_mahan (256577) <chris.mahan@gmail.com> on Thursday September 09, 2004 @11:19AM (#10201066) Homepage
    >certainly enough to evaluate the product with.

    Exactly. Like another poster said, they are doing this so people get familiar with their database, then decide to move to it later.

    By the way,

    Did some consulting for a company. It's a 30 people company. They mssql database is 7 gig now.

    Any non-trivial database job will involve an enormous amount of data.
  • by a.out (31606) * <brad@sars[ ]ld.ca ['fie' in gap]> on Thursday September 09, 2004 @11:35AM (#10201253)
    Microsoft SQL Server Express is free to use and redistribute. It supports 1 CPU, 1 GB addressable RAM and 4 GB database size.

    It's based on the core SQL Server 2005 Database Engine, including an advanced query optimizer and the new snapshot isolation level. It also supports the complete SQL Server programming model including T-SQL and CLR integration.

    http://lab.msdn.microsoft.com/express/sql/

    Did I mention that it's free to use and redistribute?
  • by Plugh (27537) on Thursday September 09, 2004 @12:35PM (#10202014) Homepage
    For the record, aside from the free (as in beer) software downloads [oracle.com], Oracle has also released a bunch of GPL'd and OSS software. IMO, Oracle really doesn't get enough "media play" for this among the Slahdot crowd.

    Oracle's Free (as in speech) software [oracle.com]

    If you saw Chuck Rozwat's LinuxWorld keynote (2 years ago, I think) you'll know that Oracle uses Linux PCs for its base development. Not just for "back-office apps", mind you, I mean a gigantic development environment with THOUSANDS of Linux PCs. The resulting inevitable patches to coreutils, etc, are all on the oss.oracle.com site above, as are Oracle's (GPLed) Clustered Filesystem.

  • by lunaman (412514) on Thursday September 09, 2004 @12:47PM (#10202166)
    As a 12-year veteran Sybase DBA and programmer, I doubt that I have the proper perspective to debate most of your points. However...
    3. Table-level locking by default. This one just blows me away; Sybase didn't support row-level locking until somwhere around version 11, and table-level locking is still the default. If you're DBAs aren't on top of things, you'll have deadlocks all over the place. They still haven't enabled it for the system tables, so make doubly sure you don't do any long-running code that touches them, or you'll have deadlocks for sure.

    Not quite. Page-level locking was always the default, where a page is 2k bytes (by default; up to 16k in current ASE.) This was never a really big problem for Sybase performance, except for applications with small very-active tables, but it always sent Oracle programmers into fits. So starting with ASE 11.x , alternative locking schemes are provided, including datapages-only locking (index pages are not locked) and row-level locking. Promotion of a page lock to the full table can happen if a significant fraction of the table is being altered in a transaction, however it's not very common.

    Current versions of ASE allow the default locking scheme to be set on a database level, and the locking scheme on each table can be set independently.

  • Re:Dual core chips ? (Score:3, Informative)

    by shic (309152) on Thursday September 09, 2004 @12:51PM (#10202222)
    This was a suspicion of mine... if an engine were to be multithreaded (i.e. capable of simultaneously processing several queries - unlike early DB2 offerings) yet only use a single processor - then it would likely not utilise native treads - but rather make use of something like Java green threads or Python threading. While this would clearly work - it would likely imply performance restrictions relative to modern DBMS which employ native threads and can run a single "engine" (in the sense of a single address space and context for transactions.) with freedom to schedule native threads to best manage IO delays and available processing hardware. I would imagine that this would be a significant restriction on the capability of the DBMS to perform under load.
  • by Anonymous Coward on Thursday September 09, 2004 @12:53PM (#10202250)
    The article refuses to load, so I can't check to make sure; but this does have all the characteristics of a demo version.

    No, it's not. It's a lite version of Sybase's flagship SQL database (the one that was licensed to Microsoft way back, and which they kept as SQL Server).

    Why did you think Sybase decided to release a free version anyway ? Corporations do nothing unless they think they will benefit from it; therefore, they tought they would benefit from releasing this version free. And the most obvious benefit is the one explained above.

    While Sybase isn't doing it purely for magnanimous reasons, it's primarily to get Linux users to try it. It does have limits (5Gb size limit on a database, and only one seat), but it's a good way to try it without committing the funds to purchase it. And as I said, it's not a demo. It's a lite version with not all of the extra bells and whistles.

  • by Tassach (137772) on Thursday September 09, 2004 @02:21PM (#10203514)
    Sybase 11.0.3.3 [sybase.com] was (and still is) free for production use on Linux and FreeBSD.
  • by jedidiah (1196) on Thursday September 09, 2004 @05:54PM (#10206509) Homepage
    Oracle SE is $150 per CAL. The minimum is 5 named users. So I did get the price wrong ($750 vs. $500).

    For a robust RDBMS that is safeguarding key corporate data, that's a pittance. If you don't need the level of robustness that most commercial RDBMS products provide then you don't need a commercial RDBMS of any sort.

    Either your data is worth paying for your RDBMS, or you don't need to bother with payware to begin with.
  • by jedidiah (1196) on Thursday September 09, 2004 @06:55PM (#10207156) Homepage
    I would gain quite a bit actually.

    Oracle SE isn't crippled. Sybase is.

    With Oracle SE I am not limited to rediculously small datasets, single cpu systems or an amount of RAM currently common on desktops and workstations.

    The same is true for postgres and mysql. That is why they are relevant in this discussion.

God made machine language; all the rest is the work of man.

Working...