julochrobak

Very interesting. I am not very familiar with many board games, but i'll definitely look at the language more!

I am a big fan of a relational model. SQL itself is OK but far from great. So, I wish you a lot of success!

I was part of a similar attempt - building a better "SQL" and relational DB. This was roughly 8 years a go. You can have a look at our GitHub Projects or look at some further links and may be you get inspired :)

* http://bandilab.github.io/ - introduction to the bandicoot project

* https://www.infoq.com/presentations/Bandicoot/ - presentation of the Bandicoot language on

* https://github.com/ostap/comp - another interesting attempt, a query language based on a list comprehension

The situation is getting serious in general. There are many many apps that people use daily. How can one find out what data is being collected per application? It would be really nice to a have a web site where the community (technical people who can inspect the apps) could maintain this information per application and a user could see a simple green/red bullets and decide whether the app is worth it or not. Really, really high level, designed for end-user (non-technical).

quick question about the indent of subclauses. How would you write a query where table3 needs to be joined with both table1 and table2? Would it change anything?

I'd suggest Tuxedo Computers - http://www.tuxedocomputers.com

I bought the TUXEDO Infinity Book - 13" Full HD screen, 16GB RAM, Intel Core i7-6500U, 1.4 kg only. It works ok, I'm using Suse Linux + Cinnamon Desktop Env. There are two things I'd improve on the laptop: the touchpad could be of a better quality, the Intel Dual AC 3160 wlan does not have the best reception (may be a problem with the antenna?).

We should not be punishing people for something they will/might cause. The system should panish only people for something they have done already.

Otherwise, we should punish you with a speeding ticket, because you will sometime in the future with some probability exceed a speed limit. Would that be ok for you?

For an existing application I personally prefer changing the index type, partitioning the table or tuning DB parameters first. It's far less risky because you don't need to change a single query and it's transaprent to the application. Sure if you cannot get the desired perfomance by tuning the RDBMS than you need to consider changing the way how the tables are modelled. From my experience, usually normalizing it one step furhter improves the performance, at least for OLTP use cases.

There are several basic concepts you can apply to improve performance in the RDBMS and still avoid denormalization. For example:

* use as many constraints as possible (this helps the query optimizer)

* use indexes which bring better performance in your use case (e.g. bitmap join index or even index-organized tables)

* apply table/index partitioning

* use materialized views as a query result cache

Does anyone have experience with the Tuxedo Computers - http://www.tuxedocomputers.com ? They have just recently released an interesting 13.3" InfinityBook.

well and here is the link - http://github.com/ostap/comp

:)

if anyone is interested there is a similar tool (called "comp") but the queries are expressed with list comprehension syntax. It also allows to join data from json and xml.

It has two modes: 1) as a commnad line

./comp -f commits.json,authors.txt '[ i.commits | i <- commits, a <- author, i.commits.author.name == a ]'

2) as a service to allow querying of the files through simple http interface

./comp -f commits.json,authors.tx -l :9090

curl -d '{"expr": "[ i.commits | i <- commits, a <- author, i.commits.author.name == a ]"}' http://localhost:9090/full

or through an interactive console on http://localhost:9090/console

disclosure: I'm a co-author, and happy to get a feedback or answer any questions :)

I know :) just having fun.

it should rather be top 8, 16, or 32...

here are some other graphical illustrations of the operators from relational algebra - http://bandilab.org/bandicoot-algebra.pdf

It's focusing on bandicoot language, but concepts are taken from the relational algebra. It should match the logic of SQL.

I like it, well done!

really? this is great! thanks for the info. Do you have any link by hand which defines these rules? (i.e. what kind of permit do I have to have, does it differ from canton to canton? ...)

It's a pity that foreigners who live for a long time in Switzerland cannot be part of this...

Yeah sure!

Suddenly there is a solution to distributed always consistent real time fully scalable reliable easy to use inexpensive database :)

Do you know this saying? "Nobody can give so much as I can promise you."

I'm sure the statements to the database comply to ACID properties. Nevertheless, from the client perspective the batching simply means that request from client one is batched together with request of client two - i.e. the atomicity is broken. If the operation fails due to problems with data from client one it impacts client two. I guess my point is, why use a database which comply to all ACID properties if you don't need them.

What do you find so rediculously good about this? I find it complicated. If I understood it properly, it's just making inserts asynchrounous (removing durability) and batches data into single statement (removing atomicity). Or did I miss something?

thank you for the explanation. I'm really sorry but I don't agree that this is the way going forward. You claim that serializability is not needed to achieve consistency. I agree up to the point that it's only possible if the conflicts are recognized and transactions aborted.

What is the benefit here? As an application developer I need to restart the transaction and hope it's not going to fail again - hence I'm serializing the execution on my own...

On top of all this, when it comes to constraints in relational model they can be complex and the probability of failing transactions is just going to grow. I can see this working only if I start relaxing on my constraints and redirecting transactions in such a way that conflicting transactions are coming to the database already serialized.

What about restarting transactions within NuoDB transparently as soon as an update conflict has occurred?

I'm not criticising it for being the same as everyone else. I'm just not sure how the whole thing works. I don't see enough information provided on the site, yet a lot of statements about providing full ACID and scalability.

re 1) and 2). I think they are related. The serialization can be done on account level. There is no need to have a single global write lock. This also implies that if the bank account transfers are typicaly to different accounts the serialization will be as often as the aborts. Hence very rare and the system will perform equally good in both cases. However, the serialization does not require further retries and doesn't force the application programmers to workaround the problems.

Thanks for the clarification. However, this does not sound like something I could use in practice.

If I have two transactions and one of them is aborted because of the changes done by the other transaction what am I as a developer supposed to do? Retry? I hope not, because a retry is in other words serializing the execution. One after another.

So, if I have a system with a lot of concurrency (i.e. bank accounts and transfers) I'd better not use NuoDB because I'd get a lot of transfers aborted, not good. If I have a system with a very little write conflicts I'd go for serializability because that gives 100% consistency and will be fast anyway due to very little conflicts.

From the wikipedia link you posted, it is fairly clear that the Snapshot isolation is good when you don't need consistency. For that you'd have to either abort every time there is a conflict or introduce write-write conflict (ie. serializing).

I'm lost here as well. Let's imagine I have COUNTER table of one numeric field VAL. All I do in transactions is:

update COUNTER set VAL = VAL + 1

Let's assume the initial state is one entry with VAL = 0. If I run the update statement in two concurrent transactions I'd expect the result to be 2 when both transactions complete. However, I don't understand how that can be achieved without serializing those transactions.

fair point about the transaction controller, this is indeed something which is not yet distributed in bandicoot. Though, I don't think it's a big deal as the tx is really simple and lightweight.

Anyway, let's go back to nuodb :) I'm really interested on how it manages the whole ACID. I did not get it from the page nor from your reply.

For simplicity, let's pick on durability only. The archive nodes listen to replication and store serialized atoms on disk. At the same time the atoms replicate the changes to other instances. Is the durability achieved by a synchronous replication?

I'm a big fan of relational theory and I'm always happy to see any activity in this space. However, their "revolutionary" distributed model seems to be similar to something which is already out there, open source, and ready for use:

http://bandilab.org/blog/2011-06-22.Ostap.Running_on_Multipl...

or maybe I just don't have enough information about the nuodb ?

SQL is not a bad language. However, it's far from flexible and reusable. The biggest issue I always have with SQL is the fact that I can hardly reuse any piece of my code.

Let me give you an example.

select vendor, model, avg(price) as price from allCars group by vendor, model;

So far, this is simple and clear. Now let's imagine someone has a requirement to calculate this for different set of cars:

select vendor, model, avg(price) as price from allCars where vendor = 'BMW' group by vendor, model;

or

select vendor, model, avg(price) as price from allCars where year > 1990 group by vendor, model;

This approach only works if I'm always selecting from the same table - allCars, and I know all the condition in advance. To reuse the actual code which calculates the average prices (select ... group by) I'd need something like this:

select vendor, model, avg(price) as price from $cars -- $cars is a variable with at least three attributes (vendor, model, price) group by vendor, model;

This way I could write my own relational operator which calculates avg prices of cars per vendor and a model no matter where the cars are coming from.

Does anyone else have the same problem as me or am I just not smart enough to figure out how to do it in SQL?