rdbms

There are quite a few independent and not-so-independent studies comparing traditional RDBMSs but I haven't managed to find any good material on in-memory databases. I am primarily interested in ones specialized for OLTP. So far, I managed to find generic white papers on TimesTen and MySQL Cluster, but I have yet to see a head-to-head comparison. There are other alternatives (e.g. from IBM), but there's even less easily available material. The information is scattered all over the web, but here's what I found out: Introduction to database benchmarking The first thing that you need to do is

I'm looking for material on persistent data structures that can be used to implement a relational model. Persistence in the meaning of immutable data structures. Anyone know of some good resources, books, papers and such? (I already have the book Purely Functional Data Structures , which is a good example of what I'm looking for.) It is straightforward to modify the ubiquitous B-tree to be persistent. Simply always alloctate a new node whenever a node is modified, and return the new node to the recursive caller, who will insert it at that level by allocating a new node, etc. Ultimate the new

I have been using python with RDBMS' (MySQL and PostgreSQL), and I have noticed that I really do not understand how to use a cursor. Usually, one have his script connect to the DB via a client DB-API (like psycopg2 or MySQLdb): connection = psycopg2.connect(host='otherhost', etc) And then one creates a cursor: cursor = connection.cursor() And then one can issue queries and commands: cursor.execute("SELECT * FROM etc") Now where is the result of the query, I wonder? is it on the server? or a little on my client and a little on my server? And then, if we need to access some results, we fetch 'em

I have in my MySQL database both longitude and latitude coordinates (GPS data). It's currently stored as: column type ------------------------ geolat decimal(10,6) geolng decimal(10,6) Question: Do I really need a data type as large as decimal(10,6) to properly store coordinate data? Since I have a combined index on the longitude and latitude, this index size is huge. If I can make it smaller without compromising anything, that would be great. WGS84 datum are usually given as coordinates in a fully decimal notation, usually with 5 decimal places, so for latitude (-90 to +90) you could use

Object-relational mapping has been well discussed, including on here. I have experience with a few approaches and the pitfalls and compromises. True resolution seems like it requires changes to the OO or relational models themselves. If using a functional language, does the same problem present itself? It seems to me that these two paradigms should fit together better than OO and RDBMS. The idea of thinking in sets in an RDBMS seems to mesh with the automatic parallelism that functional approaches seem to promise. Does anyone have any interesting opinions or insights? What's the state of play

Outside of the argument of whether or not NULLs should ever be used: I am responsible for an existing database that uses NULL to mean "missing or never entered" data. It is different from empty string, which means "a user set this value, and they selected 'empty'." Another contractor on the project is firmly on the "NULLs do not exist for me; I never use NULL and nobody else should, either" side of the argument. However, what confuses me is that since the contractor's team DOES acknowledge the difference between "missing/never entered" and "intentionally empty or indicated by the user as

I am looking at CouchDB, which has a number of appealing features over relational databases including: intuitive REST/HTTP interface easy replication data stored as documents, rather than normalised tables I appreciate that this is not a mature product so should be adopted with caution, but am wondering whether it is actually a viable replacement for an RDBMS (in spite of the intro page saying otherwise - http://couchdb.apache.org/docs/intro.html ). Under what circumstances would CouchDB be a better choice of database than an RDBMS (e.g. MySQL), e.g. in terms of scalability, design +

I have a main concept - Mail message and two derived concepts : template-generated emails free-form emails I am thinking of creating three tables to hold the data and I need your opinions on this matter (if it's bad, if it's good, how can it be improved and so on) : MailMessages Id [int] identity (autoincrement) PK ToAddress [varchar(300)] IsTemplateBased [bit] TemplateId [int] nullable FK MailBodyId [int] nullable FK (TemplateId must be null and MailBodyId must be non-null or vice-versa) StatusId [tinyint] FK MailParams MailMessageId [int] PFK ParamNumber [tinyint] Value [nvarchar(4000)]