I am new to Couchbase noSql database.
I am trying to create a view, i want this view should give result as below SQL query.
SELECT * FROM Employee e WHERE e.name = "DESM%" AND e.salary < 1000 ORDER BY e.id desc
Any suggestion is very appreciated.
If you look at existing beer samples in Couchbase (it comes with it), you will find views defined there. In admin console you can run a view. Notice when you run a view you can provide filtering criteria and sort order for the result...that might be an equivalent for your SQL like functionality. Read more on Views and Indexes
yet another option is to use Couchbase v3 that comes with its own N1QL query language that can serve as another alternative. You can try it out online here.
Related
I just started Couchbase.
I would like to find a way to query couchbase to get all buckets like
Select * from tab;
USE <DB NAME>
and retrieve all views as they are faster to pull the data from N1Q1.
select name from system:keyspaces;
Gives all the buckets. For view definitions you need to use #Matthew Groves suggestions.
You can get a list of buckets with N1QL: SELECT r.name FROM system:keyspaces r;
There is no way that I know of to query for a list views with N1QL itself.
You can use the REST API:
To get a list of design docs (which contain views): check out GET /pools/default/buckets/<bucket.name>/ddocs
For more details, check out the documentation:
Getting Views Information
System Keyspaces
I'm currently thinking about a database schema in MySQL where I store SELECT queries into a certain table column, just to execute them on-the-fly when getting selected, and having the result passed instead of the actual query.
Would this be possible somehow? Or may this be bad practice? Is it even technically possible to have a result table passed to a single field, at least so I could run the query through PDO to get back a nested result array? Are there any alternatives?
I've read that this may be achieved through stored procedures, and although I grip the concept of those I can't think of how I could use those to achieve that.
You could do this, but what purpose do you have for doing it?
I would suggest using views:
The syntax should be valid when the view is created, unlike storing
the SQL in a field which may have invalid syntax.
It's easier to debug and modify.
For example, let's say one of the queries you want to store is:
SELECT product_category, COUNT(*) AS category_count
FROM product
GROUP BY product_category;
You can create a new "view" object that defines this query:
CREATE VIEW prod_cat_count AS
SELECT product_category, COUNT(*) AS category_count
FROM product
GROUP BY product_category;
Now, the object called "prod_cat_count" is stored in the database. Internally, the database just knows that "prod_cat_count" is equal to the SELECT query we mentioned. When the view is created, the database validates the syntax (checks that all columns exist, checks you haven't forgotten the GROUP BY, for example)
Then, whenever you want to get this data/run this query, you can run this statement (in SQL or in application code, for example):
SELECT product_category, category_count
FROM prod_cat_count;
If you then decide you want to change the way the product categories are counted, you can adjust the view:
SELECT product_category, COUNT(*) AS category_count
FROM product
GROUP BY product_category
ORDER BY product_category;
Hope that helps!
We want to execute a query using Drill with the PostGIS storage plugin, the query is:
SELECT zone, count(primary_roads.id) as roads
FROM pg.test.zones, pg.test.primary_roads
WHERE ST_Crosses(geom_linestring, geom)
AND zone IN ('Astoria Park', 'Red Hook', 'Douglaston')
GROUP BY zone
ORDER BY roads desc;
Adding logs to Drill we see that what actually Drill does is splitting the query in two parts:
SELECT *
FROM "test"."primary_roads"
And
SELECT *
FROM "test"."zones"
WHERE "zone" = 'Astoria Park' OR "zone" = 'Red Hook' OR "zone" = 'Douglaston'
As you can see, it does not include the ST_Crosses function, also the GROUP BY and ORDER BY clauses.
So, is there a way we can pass the entirely query to PostGIS and avoid the splitting?
Internally Drill's planner has decided that this is the best way to run the query, and unfortunately there is no way to explicitly tell Drill not to do this. To make the planner behave differently and pushdown the ST_Crosses function along with the group by and order by we would have to make some code changes. If you'd like to see this optimization done in Drill please get in touch with the Drill team on the mailing lists. You can find all the mailing list information here.
I have a rails application and I'm currently running into performance issues at scale. I am using Rails 4 and MySQL for my backend.
I have a model named Coaches and I would like to group my response so that it only sends coaches with distinct emails.
Here is an example:
Coach.group(:email)
However when i use this code with my production workload, it takes far too long to for Active Record to produce the result, see below.
Coach Load (193743.7ms) SELECT `coaches`.* FROM `coaches` WHERE `coaches`.`deleted_at` IS NULL GROUP BY `coaches`.`email`
I have an index on the email and deleted_at column in my coaches table.
Has anyone run into similar issues in the past?
You need to also apply indexing on deleted_at column and also one proper solution is that use pagination like use data in limit format that will help you in these case.
I have created a complex view which gives me output within a second on Oracle 10g DBMS.. but the same view takes 2,3 minutes on MYSQL DBMS.. I have created indexes on all the fields which are included in the view definition and also increased the query_cache_size but still failed to get answer in less time. My query is given below
select * from results where beltno<1000;
And my view is:
create view results as select person_biodata.*,current_rank.*,current_posting.* from person_biodata,current_rank,current_posting where person_biodata.belt_no=current_rank.belt_no and person_biodata.belt_no=current_posting.belt_no ;
The current_posting view is defined as follows:
select p.belt_no belt_no,ps.ps_name police_station,pl.pl_name posting_as,p.st_date from p_posting p,post_list pl,police_station ps where p.ps_id=ps.ps_id and p.pl_id=pl.pl_id and (p.belt_no,p.st_date) IN(select belt_no,max(st_date) from p_posting group by belt_no);
The current_rank view is defined as follows:
select p.belt_no belt_no,r.r_name from p_rank p,rank r where p.r_id=r.r_id and (p.belt_no,p.st_date) IN (select belt_no,max(st_date) from p_rank group by belt_no)
Some versions of MySQL have a particular problem with in and subqueries, which you have in this view:
select p.belt_no belt_no,ps.ps_name police_station,pl.pl_name posting_as,p.st_date
from p_posting p,post_list pl,police_station ps
where p.ps_id=ps.ps_id and p.pl_id=pl.pl_id and
(p.belt_no,p.st_date) IN(select belt_no,max(st_date) from p_posting group by belt_no)
Try changing that to:
where exists (select 1
from posting
group by belt_no
having belt_no = p.belt_no and p.st_date = max(st_date)
)
There may be other issues, of course. At the very least, you could format your queries so they are readable and use ANSI standard join syntax. Being able to read the queries would be the first step to improving their performance. Then you should use explain in MySQL to see what the query plans are like.
Muhammad Jawad it's so simple. you have already created indexes on table that allow database application to find data fast, but if you change/update the (indexes tables) table (e.g: inserst,update,delete) then it take more time that of which have no indexes applied on table because the indexes also need updation so each index will be updated that take too much time. So you should apply indexes on columns or tables that we use it only for search purposes only. hope this will help u. thank u.