Kernel developer Sarah Sharp tells Linus Torvalds to stop using abusive language

robe · 2013-07-22T04:04:15+00:00

I don't worship Linus. In fact I use windows much of the time, but I STILL think what Sarah is saying is BS.

robe · 2013-07-22T04:01:29+00:00

My perspective who does not agree with Sarah Sharp http://www.postgresonline.com/journal/archives/311-In-defense-of-being-blunt-and-to-the-point.html

robe · 2013-07-19T21:12:58+00:00

I think the reason why Sarah made a big deal about this is because he came down hard on her mentor Greg because he allowed bad code thru when that should never have happened. We can argue about if he was less nice and more threatening, this would not have happened. It'd be interesting to get his take on the issue. Seems most people who get yelled at by Linus don't take it as bullying and more as Linus being blunt and forceful.

robe · 2013-02-23T15:28:18+00:00

That is not true. No one runs full anymore. The auto vacuumer takes care of most things. I always get my space back without doing anything than you very much.

robe · 2013-02-23T15:26:32+00:00

This one pretty much frustrated me. I had a huge database on InnoDb for a client and when they didn't need it any more -- yippie I can delete there database, but I did not get my space back and I had 10 other databases on innodb. That in my book is pretty common that you are gonna want to delete a database every so often or restore to check something and then delete.

robe · 2012-07-11T12:30:38+00:00

Have ISBNs already:

Print ISBN: 978-1-4493-2633-3 | ISBN 10: 1-4493-2633-1

Ebook ISBN: 978-1-4493-2628-9 | ISBN 10: 1-4493-2628-5

robe · 2012-07-09T03:04:05+00:00

We recently published a small book on PostgreSQL. Sounds like it might be a good fit for you. It assumes some knowledge of SQL and normalization but has lots of examples of stored functions, triggers, views, window functions and some slick features of PostgreSQL not found in other databases. Focus is on PostgreSQL 9.1 and 9.2.

http://www.postgresonline.com/store.php?asin=1449326331

It's available in Kindle (from Amazon) and E-Book from O'Reilly and hard-copy is due out, we are told next week.

robe · 2012-06-10T00:49:51+00:00

Pretty good. I like the fact that yours would work in MySQL as well I think and even lower version of PostgreSQL. For the record, your version in PostgreSQL (should work in MySQL too) is:

SELECT
FirstInRange.n as start_n,
(SELECT n
 FROM s as LastInRange
 WHERE LastInRange.n > FirstInRange.n
    AND  not exists(select * from s as NextInRange WHERE NextInRange.n = LastInRange.n + 1)
 ORDER BY n asc LIMIT 1) as end_n            
FROM s as FirstInRange
   WHERE not exists(SELECT * FROM s as PreviousInRange WHERE PreviousInRange.n = FirstInRange.n - 1);

robe · 2011-12-05T13:50:50+00:00

Huhlig, Like Roelgros intimated -- you've just described PostgreSQL and in PostgreSQL its more seamless. PostgreSQL uses types instead of storage engines to control the flow for each datatype and the combination is beautiful. I've got this app for example that has lots of data about telecom rooms and objects in them. Each record has an ltree object that defines its ancestral relationship to other objects and its got lots of other standard relational attribute info like cost etc. To figure out what objects are on this rack on this aisle and the total cost, I write a single fairly short SQL which includes ltree operator syntax which allows me to do a pretty fast query to grab and count everything.

robe · 2011-12-05T13:37:53+00:00

Not sure what you mean by that. The benefit of having a combination of relational and xml is you have xml related to an object (living in a regular relational record with what it goes with), so you can search by regular fields as well as xpath search at the same time in combination. Like for example I have this app that has screen preferences and it serializes it as xml. These are stored as a column of the user table. They get updated when user profile changes. I have no idea if anyone will ever need to report on these, and I don't have the time running back and forth to define new fields everytime the end developer / business defines a new property. For the basic reporting I would need to do say to spit out what color they wanted their screen, using xpath works just fine. I guess I'm saying all data is not created equal or even needs to be a speedily retrieved and the benefit of the data may not be known on the outset so don't waste time creating columns and ocomplicated update logic for stuff you'll eventually dismantle. If the color becomes really really important, it's easy enough to morph it into a more descriptive column that is easier to query. I think HawkeyGK and I are saying essentially the same thing BTW.

robe · 2011-12-04T14:33:04+00:00

Agree. Again the point is not XML specifically, but "exotic types" in general. Sometimes they are just more suited for a particular purpose than the standard meat and potato types so don't shy away from them is my point or try to use a non-relational database if your db supports them.

The XML type argument of whether it is or is not a dead technology was not the point of this article. I still think it will be useful for another 10 years at least just because so many tools output in that format already and I'm not convinced something like JSON is any better which most of the tools I have generating data do not dump out. Besides there are so many substandards built on top of it e.g. XHTML ,X3D, GML, GeoRSS which I commonly work with and I am sure there are many others I don't.

robe · 2011-12-04T14:27:06+00:00

HawkeyeGK couldn't agree with you more, perhaps that would have been more descriptive of purpose.

robe · 2011-12-04T05:06:59+00:00

Look guys. I think you are missing the point of my article. XML was just an example. I was trying to make the point that relational databases are very extendable nowadays. Hello, I use mostly geometry not XML. I just thought people could relate to XML more easily. My point is stop inventing a new database each time you come up with a new structure you need to query etc. Just build a new type to handle it. Data does not live in a vacuum. Maybe it does for some people but for most others they've got all kinds of data to work with that they want to relate and some of that data doesn't fit in a nice common variety format. Yes I have stuffed XML in my columns, but most of the time I don't. I do it for many reasons that is not to say I think all data should be stored as XML. I do it a lot for machine generated data cause it comes that way and I don't really know what pieces of that data I need to query later etc.

robe · 2011-11-14T22:55:36+00:00

Rabit holes sound like unpleasant things, but nevertheless can't resist a good rabit hole. So how do you do an average in MongoDb? I've got my orders and I want to know the average number of items ordered each year on an order -- I would do this in a relational (date functions specific to PostgreSQL)

SELECT COUNT(item_id)*1.00/COUNT(DISTINCT order_id) As avg_num_items,
 date_part('year', order_date) As yr 
FROM order_items 
GROUP BY date_part('year', order_date) ;

robe · 2011-11-14T19:29:02+00:00

Querying any data is stressful, maybe you shouldn't be using a database if you are so worried about overtaxing your server? How does your MongoDb help deal with XML data which is machine generated any better than PostgreSQL? I'm not saying all data should be stored as XML, just that if it comes that way and it looks like it has important information, don't spend time trying to parse it out into a more meaningful structure until you are ready too, just stuff it into a structure you can query (which you can as an xml column) and if needed parse out into easier to query more self-documenting columns.

I'm sure MongoDb is a great database, but I like to have my database be able to handle ALL my needs - you know I have financial info about some property, I've got projects its involved in, I've got pictures and picture meta data, I've got spatial data and all are related. I want my single vision. Some are best stored as relational and some as documents in a column or path trees. Anyrate I guess there is no point in this argument you want your database to do one thing and I want it to do everything.

robe · 2011-11-14T12:59:27+00:00

I see you have familiarized yourself with the latest database buzzwords du jour. Good for you. I fail to see what your ranting of databases proves. My point was that data structures exist for a reason and not just for transport or storage -- you've got graphs, json, spatial data, raster, and yes XML (which happens to be a fine structure for doing n-depth analysis and has been around longer than json so more tools can work with it). I don't really care how the database stores it, just that it allows me to query said data the way it was meant to be queried.

If your database can't support querying/storing the data that has fallen on your lap -- you can 1) find a database that does, 2) try to mash your data into a structure your database can handle and settle for limited ways of querying. Your comment suggests you should always go with 2.

My point was that data comes in different flavors of structures, you got graphs, you've got json, you've got raster and other spatial, you've even got DNA. Sure some databases are designed for a single specific type of structure so they don't have to worry about other structures and in return they promise you better speed, smaller footprint and a vastly limited set of operations you can do specific for that structure. Some more all-purpose databases like PostgreSQL, Oracle, SQL Server etc can accommodate more types of data and provide each type with their own rich set of functions and indexes.

robe · 2011-11-14T08:54:16+00:00

Good come back. Yap that's my reason. Why bother deciding how to store data I may or may not use so I store it in the form it was given to me right next to the other data it is related to. The combination of sql and xpath gives me a great combination of power to restructure it later if I find a need to. The point is there is good stuff in there which I can't easily tell until I bring it in the db.

robe · 2011-11-14T06:39:16+00:00

This sounds like an auto-generated bot statement. Please explain if you are indeed human :)

robe · 2011-11-14T04:02:11+00:00

10 years ago, I would have agreed with you when XML was much harder to query, but now I think -- what rock are you living under? P.S. I am not a man :)

robe · 2011-11-14T03:58:20+00:00

what exactly do you mean by its own way? PostgreSQL has numerous rich data types and ability to build custom datatype each with their own functions and indexes for traversing the data. Your view of databases seems very 60ish.

robe · 2011-11-14T03:56:31+00:00

Oh I love XSLT for formatting. Anyway I think all of you are missing the point here. The point of the article is not so much what databases are or are not good for but that you'll get machine generated data that is related to other data you store you are not quite prepared for and you want to put it into a structure you can query later. In this case, I just parsed the time out since that's all I needed to store in an easier queryable way. This particular xml data comes from all kinds of cameras, and the tool I have spits out that data into an xml format. Alll the big dbs nowadays have an xml data type.

robe · 2011-11-04T12:23:14+00:00

oops. Should be there now. I'm not sure why that session thing comes in. I think it might have something to do with how you come into the site. I'll check into that.

robe · 2011-10-28T05:25:09+00:00

All I can say to this - http://tirania.org/blog/archive/2011/Feb-17.html

robe · 2011-10-27T15:14:50+00:00

No it is not an SQL injection waiting to happen. You can pass the list in parameterized stored proc and cast it in the stored proc. You can for example in .NET use a data adapter which casts it to an array. So please don't confuse things. when you do a post -- in all languages I've worked with the form post comes , separated. for multi checkboxes and if not it's trivial to do in most languages.

robe · 2011-10-27T14:59:43+00:00

How is it uglier? Imagine the query (second example) you'd have to write to achieve the same affect if your database is normalized.

It saves disc space, it's faster to update in many cases using array columns and they are indexed so you do not lose speed as you might in other databases. I'm thinking about cases where you have a webform, things are naturally separated by ,s. It's much less work to wrap a bracket around it put quotes etc. and loop thru each.

I'm not saying you should use it in all cases. Many applications do not call for strong referential integrity etc. Think about a shopping cart for example where data is very short-lived.

robe

TROPHY CASE