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.