Use one query or several queries to PostgreSQL DB - postgresql

Question

I have the following DB
CREATE TABLE IF NOT EXISTS users (
user_uid INTEGER PRIMARY KEY,
user_name CHAR(64) NOT NULL,
token_id INTEGER
);
CREATE TABLE IF NOT EXISTS unique_thing (
id SERIAL PRIMARY KEY,
unique_thing_id INTEGER NOT NULL,
option_id INTEGER NOT NULL
);
CREATE TABLE IF NOT EXISTS example (
id SERIAL PRIMARY KEY,
variable INTEGER NOT NULL,
variable_2 INTEGER NOT NULL,
char_var CHAR(64) NOT NULL,
char_var2 CHAR(512),
char_var3 CHAR(256),
file_path CHAR(256) NOT NULL
);
CREATE TABLE IF NOT EXISTS different_option_of_things (
id SERIAL PRIMARY KEY,
name CHAR(64)
);
CREATE TABLE IF NOT EXISTS commits (
id SERIAL PRIMARY KEY,
user_id INTEGER NOT NULL,
unique_thing_id INTEGER NOT NULL,
value REAL NOT NULL,
var CHAR(512) NOT NULL,
example_id INTEGER NOT NULL,
boolean_var boolean NOT NULL
);
The tables unique_thing, different_option_of_things and examples will be static (the data will be added rarely and manually).
The table commits will be rather large. It will be the table for insert only (I will delete very rarely).
The user will be the table with user idnetification. It will be not so large as unique_thing, but will have quite a few users.
The Data of the table will be as follows:
INSERT INTO users VALUES(1, 'pacefist', 2);
INSERT INTO users VALUES(3, 'motherfucker', 4);
INSERT INTO users VALUES(4, 'cheater', 5);
INSERT INTO different_option_of_things VALUES(1, 'blablab');
INSERT INTO different_option_of_things VALUES(2, 'smth different');
INSERT INTO different_option_of_things VALUES(3, 'unique_thing');
INSERT INTO different_option_of_things VALUES(4 ,'unique_thing2');
INSERT INTO unique_thing VALUES(DEFAULT, 1, 1);
INSERT INTO unique_thing VALUES(DEFAULT, 1, 3);
INSERT INTO unique_thing VALUES(DEFAULT, 2, 3);
INSERT INTO unique_thing VALUES(DEFAULT, 2, 2);
INSERT INTO example VALUES(1, 20, 20, 'fsdfsdf', 'fgdfgdfg', 'url', '/home/user/file.txt');
INSERT INTO example VALUES(2, 24, 40, 'sfadfadf', 'dfgdfg', 'url', '/home/user/file2.txt');
INSERT INTO commits VALUES(DEFAULT, 1, 1, 55.43, '1234567', 1, TRUE);
INSERT INTO commits VALUES(DEFAULT, 2, 1, 97.85, '1234573', 2, TRUE);
INSERT INTO commits VALUES(DEFAULT, 3, 1, 0.001, '98766543', 1, TRUE);
INSERT INTO commits VALUES(DEFAULT, 4, 2, 100500.00, 'xxxxxxxx', 1, TRUE);
So, the data will be inserted ther following way:
1) I have input data of different_option_of_things, e.g., [ blablab, unique_thing], the REAL value (like 8.9999) and the number of example like `fsdfsdf`
2) It's necessary to find this record in the table `unique_thing`
a) if we've found 2 or more values or haven't found anything
results false -> the search is over
b) if we've found 1 result then
3) we are searching all values (record from unique_thing) in the 'commits' table.
a) if it has been found
a.1 search of the given example name
a.1.1 if found -> get first 25 values and check whether the current value is bigger
a.1.1.1 if yes, we make a commit
a.1.1.2 if no, do nothing (do not duplicate the value)
a.1.2 no -> no results
a.2 if no -> no results
The second function will be almost the same but without insertion, we will just make a selection without insertion (only to get data) and will find for all existing values in the table 'examples' (not only one).
The question: is it better to create 3 functions instead of one big query?
SELECT count(1) AS counter FROM different_option_of_things
WHERE name IN (SELECT * FROM unnest(different_option_of_things));
SELECT * FROM example where id=fsdfsdf;
SELECT TOP 25
FROM commits
JOIN unique_thing
ON commits.id=unique_thing.unique_thing_id where value > 8.9999;
if results-> 0 do a commit
Or is it better to write one enormous query? I am using Postgresql, Tornado and momoko.

Answer 1

I would prefer two stored procedures each to get and insert data.
Pros:
all required data is in db, so it seems like a job for db,
each call on execute needs to:
get/wait for available connection in pool (depending on your app)
run query
fetch data
Release connection
x. And between all of this operation on IOLoop
Although momoko is non-blocking, it is not for free
db can be api, not only sack of data
Cons:
logic in db means you depend on it - change db engine (for example to cassandra) will be harder
often logic in db means there is no tests. Of course you can and you should test it (e.g. pgTap)
for simple tasks it seems like a overkill
It is matter of db and app load, performance and time constraints - in other words run tests and choose solution that meets your expectations/requirements.