search

SWI-Prolog / roadmap

Discuss future development
21 stars 3 forks source link

KILLER APP - SQL SERVER EMULATOR #35

Open TeamSPoon opened 8 years ago

TeamSPoon commented 8 years ago

Imagine if we didn't have to spend all our time trying to figure out the smart ways to talk to a SQL server.. but WE ARE THE SQL SERVER!

If someone could replace M out of their LAMP stack with SWI-Prolog?

Why are people not just going all the way to replace everything?

They can't. Currently their websites are not just websites.. They have hardware devices that send and receive data to a SQL server. They should not have to port swi prolog to their proprietary hardware (and flash millions of medical devices). to know how to talk to a SWI-ServerQL.

We should use a standard that is already built into everything.. one of the big 3 and emulate it!

wouterbeek commented 8 years ago

@logicmoo This would be a killed application indeed! To some extent ClioPatria already does this, but competes in the triple store / SPARQL realm rather than the relational DB / SQL realm. The main issue here is scale. Competitors are able to store tens of billions of ground facts. This does currently not work in any Prolog. How would you solve the memory bottleneck towards scalability?

TeamSPoon commented 8 years ago

Is it correct that memory bottleneck towards scalability is a ,limit to the prolog implementations not fully utilizing the hardware of the computer? Or is it that computer hardware is not big enough yet for prolog's manner of storage?

JanWielemaker commented 8 years ago

Since many years there is a vision in hardware land that ultimately we will get uniform non-volatile memory instead of various layers of fast volatile memory connected to slow persistent storage. If that would happen, the role of memory based techniques will probably change drastically.

For now, all we can do is provide a much better interface to basically classical database technology. CQL is a step in that direction.

wouterbeek commented 8 years ago

@logicmoo That makes the SQL Server Emulator a future killer application.

@JanWielemaker Why can Prolog not store part of its data on disk? Is there an inherent reason? Even if disk-based storage would be restricted to certain ground ground facts this would already matter a lot, e.g., in the rdf/3 situation.

JanWielemaker commented 8 years ago

Oh, it can. AFAIK, such systems have existed. Right now the route is probably to connect to external or embedded database technology. From their you can make the data available at various levels. There are lots of choices, ranging from CQL-like to actually storing Prolog facts including variables. All have their pros and cons in terms of performance, sharing with other applications, transparency, etc.

wouterbeek commented 8 years ago

@JanWielemaker In that case I stand corrected: the SQL Server Emulator was a past killer application. Unfortunately it was not killer enough to still be widely used today, or it was ahead of it time.

wouterbeek commented 8 years ago

@logicmoo I've added your idea to the SWI applications Wiki, although I still believe that this killer application is difficult to realize due to scalability issues of contemporary logic DBs.

TeamSPoon commented 8 years ago

@wouterbeek thank you.

scalability issues of contemporary logic DBs.

Just being able to replace the amount of SQL that runs typical webblog or bugzilla would be nice