On 4 March 2016 at 18:03, Greg Keogh <[email protected]> wrote: > Folks, anyone using Azure Tables Storage in anger? I really like it, simple > and effective. > > What is the query syntax equivalent of SQL "not null", that is, a row has a > named property? I have a table with tens of thousands of rows, but only a > small percentage contains a property value named ErrorMessage, and I want to > select them only. Going ErrorMessage neq "" works but it's too ugly to > believe there isn't a better way.
On 7 March 2016 at 10:08, Greg Keogh <[email protected]> wrote: > However ... I need some way of finding > all the rows with an ErrorMessage property. If there is no way of doing this > without a full table scan, then it hints that I'm using the facility > inappropriately, in a "relational" way that it doesn't support. On 7 March 2016 at 13:38, Thomas Koster <[email protected]> wrote: > With NoSQL databases, you must not fear duplication if you want more > than one query to run efficiently (better than linear time). This is a > trade-off you have full control over, which is a good thing. A covering > index in a relational database also duplicates data to avoid row-id > lookups. This is not much different. On 1 April 2016 at 14:37, Thomas Koster <[email protected]> wrote: > I stumbled upon this MSDN "Patterns and Practises" page that describes > what I am talking about. > > https://msdn.microsoft.com/en-au/library/dn589791.aspx On 4 April 2016 at 11:18, Greg Keogh <[email protected]> wrote: > I like that article, it's sensible and it describes when you should and > should not use the technique of making artificial indexes to speed up > queries. > > On the weekend I ran a technical experiment to convert my personal SQL > Server database of music, videos and books into Azure tables, and I think it > went quite well. It forces you to "renormalize" everything into a different > shape to use two string keys, and in one case I did have to create an > artificial index table like the article describes. Of course there are very > limited transactions and no join concepts in Azure tables, but I don't mind > working around that to get the particular benefits of table storage (mainly > that it's dirt cheap and fast). I haven't used it yet, but Azure DocumentDB [1] sounds like it might be a slightly better fit for your collections database. It is more expensive than Azure Table Storage (but still cheaper than SQL Server). You pay for reserved resources as well as storage [2]. In DocumentDB, each "value" (document) is a JSON object, which is far more useful than a list of scalars as in ATS or relational databases, and more natural to work with from OO languages. The querying language looks like OOPified SQL. DocumentDB has secondary indexes (automatic by default [3], but can be tuned [4]). While unlikely to benefit your collections database, you can run server-side JavaScript transactions in DocumentDB [5], kind of like stored procedures. You can ignore that totally if you just want to get, put and query. [1] https://azure.microsoft.com/en-us/documentation/articles/documentdb-introduction/ [2] https://azure.microsoft.com/en-us/pricing/details/documentdb/ [3] https://azure.microsoft.com/en-us/documentation/articles/documentdb-indexing/ [4] https://azure.microsoft.com/en-us/documentation/articles/documentdb-indexing-policies/ [5] https://azure.microsoft.com/en-us/documentation/articles/documentdb-programming/ -- Thomas Koster
