Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

KILLER APP - SQL SERVER EMULATOR #35

Open
TeamSPoon opened this issue Dec 15, 2015 · 8 comments
Open

KILLER APP - SQL SERVER EMULATOR #35

TeamSPoon opened this issue Dec 15, 2015 · 8 comments

Comments

@TeamSPoon
Copy link

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
Copy link

@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
Copy link
Author

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
Copy link
Member

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
Copy link

@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
Copy link
Member

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
Copy link

@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
Copy link

@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
Copy link
Author

@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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants