I have a large table that must join to multiple Tables,
I have a query with several conditions that user may fill some of them.
I used paged method of SqlQuery.
Now, how can I get total record count? I want to implement paging on gridview and don't know how many records my query will return?
Paged should return a PageList which has TotalPages and TotalRecords properties on it.
Related
The title pretty much sums up my question, but for more detail, say I have a collection of houses, and each house can have multiple owners/tenants. These are just an ID reference to my owners collection.
So I want to query ALL my houses, but i want to populate all of their owners/tenants. If my query, something like housesModel.find({}) returns N number of results, but i ask it to .populate('owner'), will it perform an additional query to fetch those owners? keep in mind it can have many owners (for the sake of this question)
So if I query all my houses, and i get back 300 results, but i ask it to populate each doc's owners field, and each house has say on average 1.5 owners per house, is that 450 additional individual queries to the database? It feels like this is not very optimal, but that's what im trying to understand.
If it is actually doing N number of db queries for a parent query of N results, how does that affect the performance? Even more so when we get to the 1000s of results?
I have a table with the following columns
UserID (index),
SID (index),
Cause (index),
TimeValue (index),
Amount
I want to query the cause of a specific user id, Meaning I want some cause which is equal to let's say water but I want this for only one user whose id is 'someId'
The query that I have right now is doing a full table scan
SELECT Cause, Cause_Amount, UserID FROM Contribution WHERE UserID = 'u5JvslEo9DbQ7hcq4vkM74dWlxr2' AND TimeValue > 1620414948000 AND ( Cause = 'cleanAir' OR Cause = 'safeWater')
So the approach should be that it should target userId with the given id then check the TimeValue then the cause and return the result.
I hope that makes sense
Generally speaking, you should put an index on your highest-cardinality document property. That means indexing on the property that is the most unique among your data. So if you have 10 users in your system but 1,000,000 documents in your Contribution table, that will need to scan 100,000 documents.
If you are seeing high read-IOs it is like because you have a small number of users but a large number of Contributions. It seems unlikely that Cause would be high-cardinality and QLDB does not yet (9/8/2021) support range queries and so the range query on TimeValue probably won't help either.
Are there other properties on your document that you could create an index on with higher cardinality?
I would like to use Tabulator's remote pagination to load records from my database table, one page at a time. I expect that I should be able to use the page and size parameters sent by Tabulator to my remote back-end to determine which records to select from the database.
For example, with page=2 and size=10, I can use MySQL's LIMIT 10,20 to select the records to be shown on page 2 (if size is set to 10).
However, doing this precludes me from using the count of all records to determine the number of pages in the table. Doing a count on the returned records will only yield 10 records, even if there are a total of 500 records (for example), so only one pagination button will be shown (instead of the expected 50 buttons).
So in order to do remote pagination "correctly" in Tabulator, it seems I must do a query to count all records from my database (with no limits), then do a count to determine the last_page, and then do something like PHP's array_slice to extract the nth page's worth of records to return as the dataset. Or I can do 2 database queries: count all records to determine # of pages, and then do a LIMIT [start],[end] query.
Is this correct?
Tabulator needs to know the last page number in order to layout the pagination buttons in the table footer so that users can select the page they want to view from the list of pages.
You simply need to do a query to count the total number of records and divide it by the number of page size which is passed in the request. you can run a count query quite efficiently returning only the count and no data.
You can then run a standard query with a limit set on the records to retreive the records for that page.
If you want to optimize things further you could stick the count value in cache so that you dont need to generate it on each request.
how to get doc frequency of multiple fields in single query. If we query with name and address. it should return docfrequency of name index and lat_long index based on the inquiry.
As far as I know, you can't do it in a single query. Why not multiple queries, but not retrieving the full document when you don't need it (so it's faster).
I am trying to model many-to-many relationships in Cassandra something like Item-User relationship. User can like many items and item can be bought by many users. Let us also assume that the order in which the "like" event occurs is not a concern and that the most used query is simply returning the "likes" based on item as well as the user.
There are a couple of posts dicussing data modeling
http://www.ebaytechblog.com/2012/07/16/cassandra-data-modeling-best-practices-part-1/
An alternative would be to store a collection of ItemID in the User table to denote the items liked by that user and do something similar in the Items table in CQL3.
Questions
Are there any hits in performance using the collection? I think they translate to composite columns? So the read pattern, caching and other factors should be similar?
Are collections less performant for write heavy applications? Is updating the collection frequently less performant?
There are a couple of advantages of using wide rows over collections that I can think of:
The number of elements allowed in a collection is 65535 (an unsigned short). If it's possible to have more than that many records in your collection, using wide rows is probably better as that limitation is much higher (2 billion cells (rows * columns) per partition).
When reading a collection column, the entire collection is read every time. Compare this to wide row where you can limit the number of rows being read in your query, or limit the criteria of your query based on clustering key (i.e. date > 2015-07-01).
For your particular use case I think modeling an 'items_by_user' table would be more ideal than a list<item> column on a 'users' table.