Slashdot Mirror

The present (and the future) of experimental data organisation, repurposing, re-analysing, etc. is being shifted towards Linked Data and supporting graph data stores. Give it a spin.

Oracle, Franz and OpenLink (the latter having a free software version), are about to show that in practice. I think we're getting there.

And people have been doing really large databases with great performance on in-house applications. I haven't seen them live, but I have read their papers.

So, it is an important point that you raise, but I think it has a solution in near future too.

The more sensible thing would be...to use PostgreSQL which has a better license, and is more ANSI SQL compliant anyway? The "everything for free" on MySQL's case is a bit less than truthful, anyway.

You basically only get it for free for use with non-commercial GPLed software. Anything other use is effectively verboten under the 'community' edition, similarly to the way Qt is licensed (though Qt also requires that anything that licenses Qt officially, for several thousand dollars, is also proprietary, for-charge, and closed source).

Personally, it doesn't make sense to me that a 'common library' be licensed under GPL because obviously, that mostly undercuts things that don't have GPL license, such as BSD and CDDL software which isn't allowed to link to it. It's not surprising that MySQL is making it 'more closed'. They did it before when they changed from LGPL to GPL "because people were static linking and stealing the server code", and they thought the LGPL allowed that, or at least that was the excuse given at the time.

PostgreSQL, on the other hand, isn't owned by a faceless corporation that is trying to restrict your use of their software. Why suggest all of the effort of reinventing the wheel via SQLite when there's obviously an already existent, and free, alternative and equivalent to MySQL? The whole point of SQLite, as far as I understand it, is to be able to use SQL without all of the setup or server requirements, so you can dump a single file to store all database data for a single program.

Look I completely agree that one has to start with realistic things. RSS and atom are very simple, and good at what they do: really they just offer very simple file system metadata: see What Atom is all about.

Semantic Web services are a lot more complex. But at least they are RESTful. Now if a large percentage of the population finds its difficult to close xml tags, then they won't be using either atom or anything else. But that does not mean that there are not some very cool things to do in the mashup area.

Oracle is building Semantic Web technology into its database and open source mappers are appearing a little all over the place. See D2RQ as a good example, or Open Link Virtuoso. It's easy to create a mapping, I wrote mine and set up a server in one week.

Concerning ontologies versus tagging, there is no either/or here. It is simple to create a relationship for tagging. Here goes

http://blogs.sun.com/bblfish :tag "semantic", "cool", "blog" .

I have tagged my blog with three tags.

To get back to Tim Berner's Lee's remarks: my thought here is the following:

I think I am getting what this is about: standardise the interpretation of tagsoup.

If every browser interpreted tagsoup identically then one could think of tagsoup as a form of xhmtl. Tagsoup pages would be displayed identically across browsers, and one could work with the resulting xhtml DOM tree.

One major advantage of producing your site in clean xhtml would then simply be that the rendering of a clean xhtml page would be a lot faster, as it would not have to go through the extra translation to xhtml. It would of course be easier to maintain too, as the structure of xhtml would be clearer than whatever weird tagsoup rules end up being decided as the standard ones.

I'm curious if anyone has done any realworld comparisons with Xen and Virtuoso?

Here are some substantial pieces of software that can currently run on top of the Mono VM:

• The Mono C# Compiler (MCS) itself is self-hosting on Mono. This consists of "roughly 1.7 million lines of C# code."
• OpenLink Virtuoso is hosted on Mono on the GNU/Linux platform.
• MonoDevelop, though in its early stages, is already proving really quite useful as a full fledged IDE.
• XSP is already capable of running a number of complex sites, web services and all! Just have a look at the monodoc project.

... and if you still believe Mono to be "vaporware," perhaps you can explain why Novell would ever consider sponsering a project so obviously doomed to fail?

Let us not also forget that Mono is still in its infancy, whereas Qt has had the opportunity to mature over many years of constant development and deployment.

Don't get me wrong, I am thoroughly impressed with the TrollTech offering in Qt, it is just that I have a hard time buying into the whole "vaporware" pitch with regards to Mono...

Check out the iODBC.org website and the OpenLink Software website.

The ODBC components in Jaguar (and Darwin) are based on the open-source iODBC project, supported, coordinated, and maintained by OpenLink Software.

The ODBC Administrator supplied by Apple is a very basic application, capable only of assisting the knowledgeable user in keyword-value pair editing and creation of DSNs.

The OpenLink ODBC Administrator, a/k/a the iODBC Administrator, is installed with all OpenLink Single-Tier and Multi-Tier Drivers for ODBC. This Administrator handles Setup libraries, and provides full GUI dialogs for DSN configuration when the Drivers have been built for such.

Full user documentation is in progress, and developer documentation is available now from the iODBC.org site. Free support for both may be found through the iODBC.org web forum, or through the OpenLink Support pages. You can also chose to write directly to <technical.support@openlinksw.com>.

Enjoy,

Ted Thibodeau Jr Consultant OpenLink Software

Check out the iODBC.org website and the OpenLink Software website.

The ODBC components in Jaguar (and Darwin) are based on the open-source iODBC project, supported, coordinated, and maintained by OpenLink Software.

The ODBC Administrator supplied by Apple is a very basic application, capable only of assisting the knowledgeable user in keyword-value pair editing and creation of DSNs.

The OpenLink ODBC Administrator, a/k/a the iODBC Administrator, is installed with all OpenLink Single-Tier and Multi-Tier Drivers for ODBC. This Administrator handles Setup libraries, and provides full GUI dialogs for DSN configuration when the Drivers have been built for such.

Full user documentation is in progress, and developer documentation is available now from the iODBC.org site. Free support for both may be found through the iODBC.org web forum, or through the OpenLink Support pages. You can also chose to write directly to <technical.support@openlinksw.com>.

Enjoy,

Ted Thibodeau Jr Consultant OpenLink Software

A good place to starting looking is at iODBC. They provide an SDK with the necessary headers and library to get started. OpenLink provides ODBC drivers for various database engines, as well as a 'Cross-Platform ODBC SDK'.

Check here for more info.

My company uses OpenLink multi-tier ODBC drivers and PHP to talk to Microsoft SQL Server from Apache/Linux. It seems to work well, although we haven't had a chance to use it on any production websites yet, and my experiences with OpenLink's support department have been good.

I'm currently in the throws of the same type of project as you.... The only addition that I have is I need to include an accounting system written in Visual Foxpro. My requirements are to access a MySQL system that's our main database system, with some information needing to be handled via MSACCESS, and needing to query the Foxpro based system as well. To make it even more challenging, the Foxpro based system HAS to be on NT server per our support contract with the vendor! Nasty, but there's a way to make it all play nice!

I decided to use Perl instead of PHP mainly because of Perl's flexibility, runs on NT and Linux with little changes, excellent performance, etc. I'm not trying to start up a holy war here, use what you're comfortable with. The biggest hurdle was accessing Foxpro system on NT. For that I used OpenLink Multi-Tier 3.2 on the NT box. All you'll need to do there is configure the ODBC driver for Access. If you can read the *.mdb file with Excel, then the ODBC driver is configured properly. Install the OpenLink on the NT box - read the docs that come with OpenLink, it's also straight forward. You'll also need to grab the UDBC & ODBC stuff from OpenLink as well. That needs to be used to compile the DBD::ODBC perl module. Again, RTFM it's all in there. I did run into one glitch on an unrecognized command when compiling DBD::ODBC with UDBC. I only tested the module against Foxpro tables, and it did generate some errors. They were all due to SQL commands being longer than 80 chars - not a problem in my environment though.

Once that's up and running, and you've decided to use Perl - head over to the DBI/DBD Faq. Section 3 & 4 covers what you need to do. It's really not as hard as you think to connect perl to use ODBC, even on a seperate NT server. Connecting to any other ODBC compatible database works the same way.

From what I've read, PHP is just as easy. I first started developing our databases using PHP, but switched because I have other projects that Perl can be used, but not PHP. Perl looks to be slightly more complex than PHP for straight database access, but so far it hasn't been that bad. Some of the PHP code that I have looks real close to perl, so the switch isn't as painful as I thought.

I haven't tried this, but if you dump NT you could use iODBC to access the Access DB. All the parts are there, I've just never tried it. That way, you could still distribute your database in MDB format. Another option would be to keep a skeleton MDB around, and run everything on MySQL. When needed, you could just dump the MySQL tables out to the MDB tables and send it on its way. The second thing I did was set up a test network and just started working on it. I've been able to connect all the different databases together after about 12 hours of work.... Just to give you an idea of time and effort involved.

HTH

.mark