Domain: alphora.com
Stories and comments across the archive that link to alphora.com.
Comments · 21
-
Re:at least it seems more fair
producing Google SQL to compete with MS Access
Here's hoping they just buy Alphora and package Dataphor with Ajax for portal integration. Thus (or by creating some other D-class database language implementation) they could give us a sanitized SQL to avoid its many pitfalls, while having a much more powerful and simple native database engine and language.
-
Alphora Dataphor
Take a look at Alphora Dataphor. While it is not an end-user tool, it has the potential to lower your development costs so much you will be able to actually serve your users.
-
Re:Is Linux Trailing?
-
I want a real RDBMSI really love my 600 MiB FastMail account, specially because it's IMAP -- the main reason for my avoiding GMail up to now.
But searching sucks, and I depend on Evolution to do virtual folders. I'd love it even more if my email server was actually a true RDBMS where I could have, besides the traditional IMAP interface, a D (Tutorial D or D4 or something the like) language interface where I could query at will, and save my queries as views that would show up in IMAP as (virtual) folders.
BTW, even non-relational ISO SQL would be so much better than what we have now.
-
Tutorial D has already been done.. Alphora
Tutorial D with a truly relational rdbms has already been implemented. The company is Alphora. The product is Dataphor. see http://www.alphora.com/
-
Solution Today! Alphora Dataphor
To see the solution to almost all of the problems identified by Pascal, Date, Darwin and Codd please checkout Dataphor from Alphora. I am a user of their project and it is a marvel. It uses any vendor's DBMS for storage and heavy lifting, but adds untop of it true relational lanaguage and constructs. The system is so highly formalized that Dataphor provides *instant* derived user interfaces for all your tables in your existing database. After taking a few days to supply the missing information about your data that you currently cannot do in your DBMS the instant UI knows how to display all tables and forms in a logical workflow. It also handles all form validation and referencial integrity. If you change your database schema the UI is automatically updated because it is *derived*. It is not the result of some lame MS Access style wizard.
-
Re:XAML: hierarchical storage of application data
> Can you (or someone else more clueful than I) explain it again in a manner assuming less cluefulness on the part of the reader?
I really haven't the time. About data I'd point you to some reading materials: the books mentioned on The Third Manifesto, DBDebunk, some articles at DMoz and an implementation with documentation; about OSs, the GNU Hurd site seems to be unreachable now.
-
Re:GNOME is GNU. Mono is hostile to GNU.
> This slashdot posting is one of several instances in which Miguel has publicly spread FUD against Portable.Net
Very interesting posting, and an eye-opener. I for one don't care about non-copyleft software, and I had assumed Mono was GNU LGPL.
So the question now becomes, I was planning on a Mono port of Alphora Dataphor, which unfortunately is proprietary, but it is the only package I found capable of doing what I want in the middle term. I haven't started anything yet, but I was under the impression that Mono was the way to go, with their implementations of a PostgreSQL adaptor and ASP.Net. Does DotGNU and Portable.Net could support such a port in, say, one or two years from now?
That said, in the middle of FUD that post has some interesting claims, like impractible goals of DotGNU and you reading Rotor code. And there isn't any specific answer attached to this... would you care to answer in detail now, or provide an URL?
Thanks for the eye-opener.
-
Re:It's about truth, not tools
While I agree with a lot of what you are saying, it sounds like this guy is interested in making use of a card file, not a database. I'm a huge proponent of proper relational design (and keep an close eye on the D4 language's progress, since it corrects several flaws in the SQL language). However, there is a huge population of people who basically need an overblown card file to store some facts. Hypercard had an excellent system for doing so, and I find it odd that there are no semistructured databases similar to that available.
Asking yourself "what is truth" makes sense when you are setting relations in stone. I suspect this guy could get away with a semistructured database that dodges the bullet with flexibility and simplicity. Using a relational database to file recipes is like using a exotic sports car to drive across the street. Perhaps walking makes sense, sometimes.
I also take issue (ah the designer gets loose) that song title had better not be an attribute of a track because of covers. That statement is incomplete. Song titles can be the same, even if they are not covers, so the song title is nothing but a decoration as far as relationships. Even considering it brings peril. However, I doubt any user would be happy if they couldn't *search* upon titles. This common reasoning flaw is why I'm a huge proponent of non significant primary keys: often what appears to be useful in relationships turns out to be unreliable in the longer term.
Also, most MP3 databases only handle tracks. While attempting to handle songs, opus, introductions, etc, it would be best to handle those as a layer on top of the track table: that makes no changes to the track table, howevever. In that light, we have multiple truths, and they can be simultaniously expressed. Similar with albums: they are collections of CDs, meaning two layer, "CD" and "Album".
In regards to artist being an attribute of a track or song, if song is a collection of one or more tracks, I would be careful about not giving the flexability to store it at the track level: if the three sopranos sang three parts of a song, and they broke it into three tracks, I would lean towards relating tracks and artists, and having songs pull the aggrigate artist list from all tracks involved.
Down designer, down.... -
SQL is not relational
There is a huge misunderstanding: SQL is corrupted, not derived, from the relational model. Since SQL deviated from it, the relational model has been developed significantly by Hugh Darwen and Chris J Date among and above others.
So MS is not proposing a relational data storage instead of a file system, but a SQL data storage. Or perhaps not even SQL, as MS SQL Server is notoriously almost as little SQL-compliant as Oracle itself, the king of standards deviations, second only to MySQL.
BTW, if anyone tries to tell you SQL is really relational, or quasi-relational, don't belive the Marketspeak. You can't be quasi-Mathematical, and the relational model is really an implementation of set theory and predicate logic. Tables aren't relations, just like 2+2=5 is not Algebra.
Pragmatically, this prevents SQL from being as flexible, simple and performant as a relational system is. There are some examples, unfortunately mostly historical: Ingres QUEL was found to perform consistently better than SQL systems, and much better than pre-SQL systems that had SQL grafted upon; BS12 was much cleaner, as was QUEL, than SQL; nowadays Alphora Dataphor is extensible in a much cleaner way than current OO or SQL OO systems.
In its defense, it may be that Microsoft uses only the data storage engine of MS SQL Server in WinFS, just as it uses it now for Exchange. Getting rid of SQL looses many interesting, powerful capabilities, but also may unleash performance. It even could be perfected as the engine of a future, nice, relational system, if ever Microsoft wakens up to what Alphora and TransRelational are (trying to) do. But I very much doubt; most of the database field, both academic and corporate, is corrupted by SQL money; there simply isn't enough cultural critical mass for a big company as Microsoft to steer its course from SQL to relational.
Even so, this could be the single most important contribution of Microsoft to the Informatics field, on a par with making the x86 computer a commodity. Even a sub-relational system can be so much better than what is around; this, together with Moore's Law making inherent Wintel inefficiencies irrelevant 80% of the cases, could pose a very big threat to the competitive position of free software. Granted the GNU/Hurd, or perhaps even Eros, could implement something even better than WinFS, truly relational and with orthogonal persistence in the physical layer (Eros) and/or a functional language application layer (GNU/Hurd). But there is no talk of doing so yet, and it would take a long time to bring these systems to where GNU/Linux is now.
-
Re:Data integrity?
Chalk up one more person who's missed the point.
This isn't a relational database. Those techs you mention are used to make a denormalised SQL database act like a normalised SQL database; they aren't needed if your relational database is normalised or you're not using a relational database at all.
I don't believe I have missed the point at all. I am painfully aware that the technology in question is not a relational DBMS. But, normalization (with foreign key constraints) is only the beginning of the constraints needed to create a real database. There are constraints that can be placed on columns, on tables, even on specific types with some systems, and there are *database* constraints (when the system is in condition X, don't allow Y, etc...). Triggers are not the optimal solution for database-level constraints, but that is how most SQL systems are limited.
Yes, I agree that SQL systems are limited, by design. The world has not seen a truly relational DBMS, with the possible exception of Dataphor (which I dislike for other reasons). The relational model is a logical model. It doesn't "care" which implementation you use. DBMS's are just applications. There is no reason you can't do one in Java. It's not about the language, but about the concept. The relational model offers logical advantages that cannot be found in ANY other system. If any other system achieved those advantages, it would become de facto relational. End of story.
No, the point is being missed by a great many people. This whole thread here really is about physical storage optimization, and running in memory. There is no reason a relational DBMS can't run in memory. That is simply an implementation detail. If the Prevayler application framework achieved the level of logical relational operators and constraints of an RDBMS, then it would become an RDBMS. But it seems pretty obvious that this is not its purpose.
I'm glad you like DBDebunk.com. It helped me, see these concepts in much more clarity. Go back and read the site more carefully, and you will see every argument in this Slashdot thread examined and reexamined. Look for the whole logical-physical confusion thing ;-).
This is language-specific, or application-specific.
Oh? Which one, then? Language, or application? Have you read the page?
Yes, it has many languages, but if you try to access your Java Prevayler application data from PHP or Perl, you are going to have to re-implement all your integrity constraints in those languages. That's my point. No longer will you have a single point of control for your business rules, or the logical model of your data.
It's NOT intrinsically language specific, although if the languages you're wanting to use together don't have any way of talking to each other you're out of luck (although I don't see how SQL could help you there).
Huh? This is the most obvious one of all. With SQL, my VB, Java and Perl application could all interact with the same DBMS without needing to talk to each other. Thats a perfect solution in the real world.
Your other problems are real, of course; but they're also very real for any real database, relational or otherwise.
I understand that complex database design is always a difficult thing. And I recognize that there is nothing a relational DBMS can do that can't be re-implemented in application code. But that's my whole point. Separation of operations. Your data should have a single point of control for the logical constraints in the data, and that point of control should be a logical firewall between the data, and everything else that happens in the application.
Also, in the end there is also nothing that an OO DBMS can do that a truly relational DBMS can't. This is what many people don't understand about the true relational model. With the right kind of RDBMS (not the typical SQL ones), there are many more things that are possible than just messing around with base types and simple 3NF normalization. And with updateable views, functions, and logical RULEs (check out PostgreSQL), you can tailor the external access to the application in any way you want, without changing your base table design. This is power. -
Re:This is an overrated rant about bad coding
> SQL - This example is a straw man. The problem with SQL is not the abstraction it provides, but the complexity of dealing with unknown table sizes when you are trying to write fast generic queries.
Correct conclusion, wrong reasons. The problem with SQL is not the complexity of getting good performance, but the low quality of its abstraction. A truly relational system might even be slow, but it would be uniformally, thus predictably and treatably, slow.
A relational system should never give different performance for different syntax if the result is the same. The optimizer should know the structure and sizes of all objects and always get the same access path if the result of the expression is the same. SQL fails because many SQL constructs are ill-defined or even wrong.
All performance tuning must be done by DBAs at the mapping between the logical and physical schemas, but SQL makes that impossible, specially after SQL:1999. See DBDebunk for more details.
-
Re:Non-leaky abstractions
> There's been a trend away from non-leaky abstractions.
[...]
> SQL offers an abstraction for which the underlying database layout is irrelevant except for performance issues.If you are right, it means we will get a real relational DBMS soon. Wait, it already exists, but no one cares.
Moral: a trend exists when there is awareness not only the problem, but also of possible solutions. Everyone knows SQL is a problem, but most people think the solution is OO, so the real solution is overlooked.
-
Re:OOP is great, RIGID object models are bad
> Things that are more likely to change are things where non-equality comparisons are less likely.
And why non-equality comparisons should be special?
> For example, with CustomerID, you almost never use greater-than or less-than.
Which comparison operator are mostly used is immaterial. The real thing is the domain itself. For example, CustomerID cannot be compared, say, to SaleID. They are different domains. Now, if you map any of this domains to a specific language data type, and you want this language to use dynamic typing, your call. But do not let your language do meaningless cross-domain comparisons.
> Perhaps we should make a distinction between "street relational" and "pure relational".
No, we should make a distinction between relational and non-relational, SQL being non-relational. But if you want, you can call it quasi-relational. But it is not relational, simply because relations are sets, while SQL tables are bags. And bags, by definition, are not sets and do not behave as such.
> Until/if the industry starts to back pure relational, I am not going to assume/wait for it to happen, and try to work with what we have now WRT "relational".
So you only will used something good if everyone does? BTW you do not have to wait, unless you want it free. Go Alphora Dataphor.
> I am all for overhauling SQL.
SQL must be thrown away, not overhauled. It is too inconsistent, illogical and idiosyncratic for overhauling.
> I have kicked around new syntax and structure for such. It tends to resemble functional programming in many ways.
If you do not want to do the right thing and go relational, at least do not wast your efforts by duplication. Go SchemeQL.
-
Re:OOP is great, RIGID object models are bad
> One problem with strong-typing based on fields that come from the database is that if you change the schema type, then it is out of sync with the code.
But this is good! If a data type changes, code around it must change. The same comparisons are not anymore valid, for instance.
The way too keep code stable is to begin with a good data model. Granted, SQL makes this impossible by not supporting domains as required by the relational model: what it calls domains are ridiculous. But if we had real domains, and domain Specialization by Constraint, then they would be stable and precise, and seldom code would need a data type change.
> Relational databases are not going away
I sure hope not, once they arrive indeed. Up to now, we have only Alphora Dataphor, and that is not yet a full-blown DBMS, not to mention being proprietary and MS W32-only. Remember and repeat to yourself: SQL is not relational!
Be sure to read The Third Manifesto and its clear, logic, simple proposal for rich, precise, reusable type hierarchies thru Specialisation by Constraint.
-
Alphora Dataphor DAE
The Alphora Dataphor DAE is the first relational database management system since IBM BS12 and the QUEL version of Postgres.
It was coded for MS
.Net, thus it should be readily portable to Ximian Mono or GNUs & Southern Storms DotGNU Portable.Net.If such a potentially useful software became publicized and free software, we could have a really innovating no Marketspeak intended , probably killer application the proprietary vendors would have a hard time scrambling after.
And that with unreprochable theoretical foundations attested by the luminars of the field.
-
Alphora Dataphor DAE
The Alphora Dataphor DAE is the first relational database management system since IBM BS12 and the QUEL version of Postgres.
It was coded for MS
.Net, thus it should be readily portable to Ximian Mono or GNUs & Southern Storms DotGNU Portable.Net.If such a potentially useful software became publicized and free software, we could have a really innovating no Marketspeak intended , probably killer application the proprietary vendors would have a hard time scrambling after.
And that with unreprochable theoretical foundations attested by the luminars of the field.
-
Alphora Dataphor DAE
The Alphora Dataphor DAE is the first relational database management system since IBM BS12 and the QUEL version of Postgres.
It was coded for MS
.Net, thus it should be readily portable to Ximian Mono or GNUs & Southern Storms DotGNU Portable.Net.If such a potentially useful software became publicized and free software, we could have a really innovating no Marketspeak intended , probably killer application the proprietary vendors would have a hard time scrambling after.
And that with unreprochable theoretical foundations attested by the luminars of the field.
-
Re:Integrated database computers: IBM AS/400
> I meant "street relational", not Codd theory-book relational.
The problem is that street relational is no relational at all, since it violates the basic theoretical principles of the relational model. BTW it’s not only Codd, but also Christopher J Date, Hugh Darwen, Fabian Pascal and now Nathan Allan.
It makes no sense to speak about Codd theory-book relational. There is a post-Euclidian Math with is still Mathematics, and indeed superseeds Euclid; but it evolves from the Euclidian fundamentals to the point of redefining them. SQL, OODBMSs and other database models up to this day are either pre-relational or just plain confusion of mind which seems works just because people never considered they could have something much better &ndash -- that they could have had it for twenty years already.
-
Re:Integrated database computers: IBM AS/400
> But DB2 is generally *relational*, not OO.
IBM DB2 is SQL. While SQL claims to be relational, it isn’t. There are only two faithful implementations of the relational model, one is obsolete, the other is still a beta.
-
Re:dbdebunk.com
> A valid point, and I may read some more of the articles on the site.
Please do. You may also be interested in some stuff at DMoz Relational Implementations and Model listings... I created these, they have been taken over with no explanations and I could never get back into DMoz, again with now explanations as to why.
> But I'm not likely to buy books merely to understand an argument which appears dubious and impractical.
‘Dubious and impractical’ in which grounds? In fact, it’s hardly dubious because they are the authors and maintainers of the relational model; and it’s not impractical at all because there were already at least two faithful implementations of the relational model already, one currently in beta and other in production usage for twenty years already, not to mention other implementations, partial or not that aren’t perfect but are still more faithful to the model.
> It seems that the core issue is the authors' demand to define 'relational database' in a sense that predates SQL and ignores all recent evolution.
The whole point is that SQL is an involution.
> Has anyone written a true relational database? If not, what are they waiting for? Is such a database vastly harder to write than the pseudo-relational databases being used today?
Yes, as I pointed above. The issue here is that the market has in the eighties taken the ‘safe’ option (IBM SQL/DS) and fell in love with it over the better alternatives, just as it did with MS Windows over Unix and OS/2 in the nineties.
> Sounds like another collision between reality and ideal. In an ideal world, the structure and business model of a company would be known in advance and someone would create a unified data model for the company. In practice, large companies purchase many different software packages that come with their own database schema.
Again that’s a failure in the tools and processes. Even if SQL is fundamentally flawed, if it was really standard integrating all these databases wouldn't be so hard; if it was really distributed it would be a given; if on top of this all these products were properly documented, this job would be almost done already.