Java Community News - Gavin King: In Defence of the RDBMS

Articles |
News |
Weblogs |
Books |
Forums

Artima Forums | Articles | Weblogs | Java Answers | News

Sponsored Link •

Java Community News
Gavin King: In Defence of the RDBMS

195 replies on 14 pages. Most recent reply: Jun 20, 2007 6:11 AM by James Watson

Welcome Guest
Sign In

Back to Topic List

Reply to this Topic

Search Forum

Threaded View


Previous Topic		Next Topic

Flat View: This topic has 195 replies on 14 pages [ « | 1 2 3 4 5 6 7 8 ... 14 | » ]

James Watson

Posts: 2024
Nickname: watson
Registered: Sep, 2005

Re: Gavin King: In Defence of the RDBMS

Posted: May 29, 2007 9:25 AM

> I had suggested using views as an abstraction layer, not
> as a mapping layer. It is not a mapping from table(s) to a
> class, though, in effect, it comes down to the same. The
> point is that the view represents the business need, not
> necessarily the class's view of the data.
>
> The key is that different applications can use different
> views based on the same underlying data structures. If the
> application requirements change, or the classes change,
> then we can always change the views without affecting the
> internal database structure. For example, let us say that
> our Person class now needs the home address of the person.
> Just change the person_view to fetch the home address. The
> class has changed, the view has changed, yet it has not
> affected the underlying data structures. In this sense,
> views can be used to serve as an abstraction layer, hiding
> the data structures form the application.
>
> At the same time, we can change the internal
> representation of the database for whatever reason, and
> change the views to conform to the new internal
> representation without any application needing to know of
> this change.
>
> Seen this way, the view is more of an interface between
> the application layers and the database; just like stored
> procedures and functions should be. Interfaces, as we all
> know, should not change very frequently. The
> implementation of the interface can change as often as
> needed, without affecting the applications that use it.

I understand what you are saying but after talking to some people with really string data modeling backgrounds, there are a lot more downsides to views than I though initially (although I still think they are under-utilized.) One of the things that would be hard on my team is that we have so many slightly different needs. SQL against views can have performance limitations as compared to raw queries in a number of cases and views that are too specific will lead to a ballooning population that will be difficult to maintain.

Views are a powerful tool but they alone are unlikely to resolve the entire Object to database mapping issue alone.

robert young

Posts: 361
Nickname: funbunny
Registered: Sep, 2003

Re: Gavin King: In Defence of the RDBMS

Posted: May 29, 2007 9:38 AM

> > The biggest mistake that OO programmers make is to
> start
> > their design with the application and leave the
> database
> > till last.
>
> Designing the perfect DB structure first is one approach.
> But not very Agile.
>
Rails now has Migrations, which are the Agile way to change the database structure as development proceeds. It is very cool. Expect to see the equivalent elsewhere soon.

Alternatively, as I've mentioned more than once on similar threads here at Club Artima, there are database driven frameworks. Andromeda is the one I like the best. Firestorm has two (commercial) implementations. More appear as time goes by. Change the schema, push a button, get a new bunch of application source files. Why not?

Well, the argument is that the application code is too complex. Couldn't possibly be described in RDBMS constraints. But consider: any constraint on the data that isn't in the database constraints must be HARD CODED in the application. How many coders would admit to doing that? And now, the database no longer knows whether its data is consistent. If you don't care whether the database is consistent, then why bother with a database? Suck it up, and just write purpose built files, multi-user transaction manager, etc. And, if the coder knows what to HARD CODE in the application, and the database is intended to be consistent, then why not put the behaviour of record with the data, where it won't get lost?

Model Driven Architecture, not in vogue admittedly, takes the view that both the database and the application code are derived from a common specification. I'm not opposed to that, either.

The point of the RDBMS being that data and its constraints (and all of them) belong together, in one place, at one time. Coders don't like that, since it tends to reduce their influence and control. All they have to do, if anything, is make a pretty pixelated UI. Nobody wants to be made redundant.

And the arguements about legacy databases being lousy and all strikes me as another red herring; those who talk of OO databases and such must be talking about so called green fields development. So, let's compare apple to apples.

Tony Marston

Posts: 37
Nickname: tony32
Registered: May, 2007

Re: Gavin King: In Defence of the RDBMS

Posted: May 29, 2007 9:46 AM

> > Some (OK, a lot) of OO programmers dislike my approach
> > because it is different from what they have been
> > taught. One table per class? No real OO
> > programmer would do that! It is not "pure" enough!
> > That's all BS as far as I am concerned. My approach
> > works, and works well, and knocks the spots off many
> > other methods I have seen.
>
> It seems to me that this only works if the programmer has
> control of the database schema.

Correct. I have given up working with other people's second rate application designs with 3rd rate database designs, so nowadays I only work on applications where I have total control over everything. That means new applications (which I design), new databases (which I design) using a RAD framework (which I designed and built).

> Most of the time, I am
> working with preexisting tables that may be denormalized
> or just plain poorly designed. I know your prerequisite
> is that the database is perfect but what's your
> contingency plan?

I have stopped working for companies which have crap database designs.

> So I think that if the database is perfectly normalized,
> your approach will work but in reality most projects do
> not have this luxury.

To me it is not a luxury, it is a prerequisite. You wouldn't ask an olympic runner to run in badly fitting shoes over a badly ploughed field, so why should a software developer be expected to work with a poorly designed database?

> In addition, you've coupled your application code to the
> structure of the database. If the
> database is changed, it means you either have to redesign
> your classes or you need to have some sort of mapping to
> the new structure. I think in most cases, the mapping is
> going to prove to be the more feasible approach.

You have totally missed the point of my approach. If I change the structure of an existing table all I do is import the modified schema into my data dictionary, then export the modified structure to my application. I do not have to rebuild the class file for simple changes in structure.

Because my method makes it easy to keep the database and application structures in sync, I find that should the requirements change I have no qualms about changing the database structure. I have worked with both perfect and imperfect database designs, and I know which I prefer.

Morgan Conrad

Posts: 307
Nickname: miata71
Registered: Mar, 2006

Re: Gavin King: In Defence of the RDBMS

Posted: May 29, 2007 9:54 AM

> > I'm just wondering how "Object-like" your table-derived
> > objects actually are. This is where I have a lot of
> > concerns about your approach.
>
> They are VERY "object-like" insofar as they are classes
> which need to be instantiated into objects at runtime.
> They also make extensive use of encapsulation, inheritance
> and polymorphism which are the only requirements in
> OO programming.

We really need to better define the various styles / implementations of OOP. Cause "it's a class, therefore it's OOP" doesn't really cut it for me. I'm going to coin two new terms.

LOOP "Light" OOP (some might say L == lousy).
e.g.: Typical Javabeans with little behavior and gobs of exposed data via getters and setters. Much behavior is held elsewhere in services or procedures, which ask the objects for data.

SOOP "Strong" OOP (some might say S == superior) Behaviorally complete objects with little exposed data. You generally ask the object to do something, not to tell you it's data.
e.g.: Take an OOAD class, read Allan Holub or the Naked Object people.

One class per table easily qualifies as LOOP. Turning it into SOOP is much harder. Now, maybe it's just not worth it. One of Ted Neward's proposals was to (paraphrasing) abandon SOOP if the RDB is a strong requirement.

James Watson

Posts: 2024
Nickname: watson
Registered: Sep, 2005

Re: Gavin King: In Defence of the RDBMS

Posted: May 29, 2007 9:59 AM

> Alternatively, as I've mentioned more than once on similar
> threads here at Club Artima, there are database driven
> frameworks. Andromeda is the one I like the best.
> Firestorm has two (commercial) implementations. More
> e appear as time goes by. Change the schema, push a
> button, get a new bunch of application source files. Why
> not?

The immediate though would be that a lot of code that depended on the last button push would likely be broken.

> Well, the argument is that the application code is too
> complex. Couldn't possibly be described in RDBMS
> constraints. But consider: any constraint on the data
> that isn't in the database constraints must be HARD CODED
> in the application. How many coders would admit to doing
> that?

What's the alternative?

> And now, the database no longer knows whether its
> data is consistent. If you don't care whether the
> database is consistent, then why bother with a database?
> Suck it up, and just write purpose built files,
> , multi-user transaction manager, etc.

Or use a database and get these things, plus a lot more with a lot less effort.

> And, if the coder
> knows what to HARD CODE in the application, and the
> database is intended to be consistent, then why not put
> the behaviour of record with the data, where it won't get
> lost?
>
> ...
>
> The point of the RDBMS being that data and its constraints
> (and all of them) belong together, in one place, at one
> time. Coders don't like that, since it tends to reduce
> their influence and control. All they have to do, if
> anything, is make a pretty pixelated UI. Nobody wants to
> be made redundant.

I've never worked with a DB that had the facilities to represent all the necessary constraints on the data. The normal DBA response is to use stored procedures but what that tends to be is just code written in a fairly rudimentary procedural language.

James Watson

Posts: 2024
Nickname: watson
Registered: Sep, 2005

Re: Gavin King: In Defence of the RDBMS

Posted: May 29, 2007 10:16 AM

> > > Some (OK, a lot) of OO programmers dislike my
> approach
> > > because it is different from what they have been
> > > taught. One table per class? No real OO
> > > programmer would do that! It is not "pure" enough!
> > > That's all BS as far as I am concerned. My approach
> > > works, and works well, and knocks the spots off many
> > > other methods I have seen.
> >
> > It seems to me that this only works if the programmer
> has
> > control of the database schema.
>
> Correct. I have given up working with other people's
> second rate application designs with 3rd rate database
> designs, so nowadays I only work on applications where I
> have total control over everything. That means new
> applications (which I design), new databases (which I
> design) using a RAD framework (which I designed and
> built).

You must be every employer's dream. Do you bring this up in interviews?

> > Most of the time, I am
> > working with preexisting tables that may be
> denormalized
> > or just plain poorly designed. I know your
> prerequisite
> > is that the database is perfect but what's your
> > contingency plan?
>
> I have stopped working for companies which have crap
> database designs.

That's a great solution for you, I guess. Not so much for those companies.

> > So I think that if the database is perfectly
> normalized,
> > your approach will work but in reality most projects do
> > not have this luxury.
>
> To me it is not a luxury, it is a prerequisite. You
> wouldn't ask an olympic runner to run in badly fitting
> shoes over a badly ploughed field, so why should a
> software developer be expected to work with a poorly
> designed database?

We can all play the "pick a convenient analogy" game. Here's one: what if a worker refused to work on a gas leak because the weather wasn't perfect?

If you can manage to be such a prima donna and be in good standing with your employer, then more power to you. I personally do not like to work with people who can't (or refuse to) work through problems like this.

> > In addition, you've coupled your application code to
> the
> > structure of the database. If the
> > database is changed, it means you either have to
> redesign
> > your classes or you need to have some sort of mapping
> to
> > the new structure. I think in most cases, the mapping
> is
> > going to prove to be the more feasible approach.
>
> You have totally missed the point of my approach. If I
> change the structure of an existing table all I do is
> import the modified schema into my data dictionary, then
> export the modified structure to my application. I do not
> have to rebuild the class file for simple changes in
> structure.

I never meant to imply that you would. What happens to all the dependencies on that class?

> Because my method makes it easy to keep the database and
> application structures in sync, I find that should the
> requirements change I have no qualms about changing the
> database structure. I have worked with both perfect and
> imperfect database designs, and I know which I prefer.

I wonder if myself and everyone else would consider your database structures to be perfect. My experience is the more that someone thinks their shit doesn't stink the more it actually does.

Morgan Conrad

Posts: 307
Nickname: miata71
Registered: Mar, 2006

Re: Gavin King: In Defence of the RDBMS

Posted: May 29, 2007 2:17 PM

For the record, I did figure out (I believe) how to dynamically create a HibernateTemplate to a database not known at XML configuration time. Code is fairly simple, but it took a day and a half to figure out / Google search on the right terms. (I didn't know much about gory details of Spring, I now know a lot more!).

Contrast to one line of code in db40...

Kevin Teague

Posts: 15
Nickname: wheat
Registered: Mar, 2006

Re: Gavin King: In Defence of the RDBMS

Posted: May 29, 2007 5:40 PM

> Kevin, see Robert's earlier post.

I think I worded my original statement in a far too general and wide sweeping manner (OODBMS is more secure than RDBMS). Any particular db and application implementations are going to dictate security to a far greater degree than your style of data persistence.

> Just because a significant number of web programmers
> rs design applications that permit SQL injection it does
> not follow that RDBMS are insecure. It is a trivial matter
> to take care of SQL injection: make sure there is no SQL
> code in your application, only references to keys that
> obtain the required SQL statement from some sort of
> configuration system (file, database, whatever.)

If there is no SQL code in your application, how does your application update the database?

I was originally just wanting to point out that there is a class of security exploits exposed in having an SQL server in-place that does not exist for an object persistence system. I was thinking about web apps that need to protect against things like:

http://example.com/data/update?title=Hello;INSERT NASTY SQL HERE

There is no sequence of data that a user can send to an object persistence system to perform that kind of exploit.

However, as a Zope developer, it's also worth pointing out that we have the odd habit of storing untrusted code in the database, so that opens up a whole other set of security escalation exploits that are unique to that environment.

> As Robert Young mentioned, this is a strawman argument. As
> I mentioned earlier, you can, in fact, have more fine
> grained access to data using RDBMS than for an OODBMS,
> including row-level security such as that provided by
> "Trusted Oracle" earlier.

This is not true. Zope provides row-level and even field-level security to provide very fined grain access to data using an OODBMS.

Also, as a developer with a strong preference to open source neither MySQL nor PostgreSQL provide that level of security. I also work in the field of grant-funded genomic research, where having freely distributable systems is often a requirement of systems we build.

Kevin Teague

Posts: 15
Nickname: wheat
Registered: Mar, 2006

Re: Gavin King: In Defence of the RDBMS

Posted: May 29, 2007 7:14 PM

Here is an interesting read on some of the joys of using an object database, and why you might not to want to have a direct one-to-one table to class type of relationonship.

http://griddlenoise.blogspot.com/2006/03/yay-object-database.html

Kevin Teague

Posts: 15
Nickname: wheat
Registered: Mar, 2006

Re: Gavin King: In Defence of the RDBMS

Posted: May 29, 2007 7:24 PM

> Rails now has Migrations, which are the Agile way to
> change the database structure as development proceeds. It
> is very cool. Expect to see the equivalent elsewhere
> soon.

Zope has had Generations (equivalent to Rails Migrations) for around
the same time. The need to easily handle data migrations in a controlled
fashion is necessary for any system regardless of OODBMS or RDBMS.

Rails the framework is also very much of the opinion that the
expression of the data model should be done in one place only,
but that place is in Ruby code and not in the database.

I disagree with Rails about on this point, as I think that
one-and-only-one place should be Python code ... :P

Also, it worth noting that both Rails (RDBMS) and Plone (OODBMS) both
have elements in place that are analogous to the the approach mentioned in
another post of "generating code based on the schema". The only difference
is that because these systems are written in a dynamic language they generate
that code at run-time as opposed to writing and compiling static Class files
on disk first.

> Well, the argument is that the application code is too
> complex. Couldn't possibly be described in RDBMS
> constraints. But consider: any constraint on the data
> that isn't in the database constraints must be HARD CODED
> in the application. How many coders would admit to doing
> that? And now, the database no longer knows whether its
> data is consistent. If you don't care whether the
> database is consistent, then why bother with a database?
> Suck it up, and just write purpose built files,
> , multi-user transaction manager, etc. And, if the coder
> knows what to HARD CODE in the application, and the
> database is intended to be consistent, then why not put
> the behaviour of record with the data, where it won't get
> lost?

This barely even makes any sense.

In a web application it's often necessary to express the constraints of
the data model in more than one location. Once in the database to ensure
data integrity, a second time in Javascript so that a user doesn't have to
submit a form before realizing they've made an error, and a third time in the
application server if you want to do data validation using AJAX, or if you
would like to handle invalid data error messages in a sane fashion.

For example, if you need to express an invariant (field A > 10 if field B is < 5),
and your only method of detecting invalid data is attempting an INSERT
into a relational database, it seems like it would be quite difficult to
convey that data input error to the end user in a manner that they could
understand.

In my experience, the data model and integrity expressed by a database has
the tendency to evolve towards a schema that promotes performance. Where as
the UI simultaneously evolves in another direction to support a user interface
that supports usability.

Again, this is exactly where frameworks like Rails have moved towards.
The schema is highly optimized, while the validation of and presentation of
data and other CPU intensive concerns can easily be parallelized across
multiple servers.

robert young

Posts: 361
Nickname: funbunny
Registered: Sep, 2003

Re: Gavin King: In Defence of the RDBMS

Posted: May 29, 2007 7:54 PM

> > Well, the argument is that the application code is too
> > complex. Couldn't possibly be described in RDBMS
> > constraints. But consider: any constraint on the data
> > that isn't in the database constraints must be HARD
> CODED
> > in the application. How many coders would admit to
> doing
> > that? And now, the database no longer knows whether
> its
> > data is consistent. If you don't care whether the
> > database is consistent, then why bother with a
> database?
> > Suck it up, and just write purpose built files,
> > , multi-user transaction manager, etc. And, if the
> coder
> > knows what to HARD CODE in the application, and the
> > database is intended to be consistent, then why not put
> > the behaviour of record with the data, where it won't
> get
> > lost?
>
> This barely even makes any sense.
>
> In a web application it's often necessary to express the
> constraints of
> the data model in more than one location. Once in the
> database to ensure
> data integrity, a second time in Javascript so that a user
> doesn't have to
> submit a form before realizing they've made an error, and
> a third time in the
> application server if you want to do data validation using
> AJAX, or if you
> would like to handle invalid data error messages in a sane
> fashion.

It makes sense if one views constraint definitions as a Repository responsibility. That's what database driven frameworks do: generate UI editing code which is a (user friendly) duplicate of the database constraints. I never said that constraints are *only* enforced at the database; only that the "constraints of record" are stored there. The app server, UI, or Aunt Milly can have their own versions (language specific). Folks happily slog through XML to generate code (I work with such a kludge). I'd rather do it from the database.

>
> For example, if you need to express an invariant (field A
> > 10 if field B is < 5),
> and your only method of detecting invalid data is
> attempting an INSERT
> into a relational database, it seems like it would be
> quite difficult to
> convey that data input error to the end user in a manner
> that they could
> understand.

Just provide a User Friendly string for the SQLCode. Standard practice. Again, generable from the schema.

>
> In my experience, the data model and integrity expressed
> by a database has
> the tendency to evolve towards a schema that promotes
> performance.

If you mean "I denormalize for speed"; not on my watch. With cycle and memory costs reaching the noise level, 5NF databases are more logical than ever. Buffer the piss out of the tables; performance will be fine. There's a recent article, don't have the cite (Coding Horror, IIRC), that Google has found that the majority cost of ownership is all those electrons needed. Hardware isn't it. And then there's the multi-core issue of parallelism; RDBMS builders have been doing that longer than anybody else. They know how to do it better. There will come the time when such multi-beasts won't go faster on serial code (Amdahl's law). So, the only feasible way to get more throughput is with inherently parallel code. That's the database. The PC becomes just an Xterm, or 3270.

Where as
> the UI simultaneously evolves in another direction to
> support a user interface
> that supports usability.

Well, again, KISS. The relational model strives to simplify as much as possible; one fact, one place, one time.

And for those who think AJAX is some new way of doing things: Unix database/VT-100 systems from the 1980s provided character mode interface out of the box. Nothing new.

Mark Thornton

Posts: 275
Nickname: mthornton
Registered: Oct, 2005

Re: Gavin King: In Defence of the RDBMS

Posted: May 30, 2007 1:30 AM

> friendly) duplicate of the database constraints. I never
> said that constraints are *only* enforced at the database;
> only that the "constraints of record" are stored there.

While I store my constraints in the database, the database server doesn't understand or enforce most of them. It simply isn't practical for databases to enforce some types of constraint.

Achilleas Margaritis

Posts: 674
Nickname: achilleas
Registered: Feb, 2005

Re: Gavin King: In Defence of the RDBMS

Posted: May 30, 2007 3:07 AM

> Achilleas, what does the term normalization mean when
> referring to objects?

It means not to have the same information in two objects; i.e. exactly the same as in databases.

>
> As far as I am aware of, the term normalization is
> conspicuous by its absence in every article and book on OO
> philosophy and practice.

That's because it's almost apples and oranges: OO is about organizing code, DBs are about organizing data. But objects will contain data at some point, so these objects have to be organized like databases.

>
> What I've seen is an explosion of classes and class
> hierarchies with sub-classes only differing in the values
> that one or two fields may take, not in behaviour. And
> this seems to be a very common Java/J2EE design pattern
> (anti-pattern?). In short, bloat.

The reason for the bloat is that original meaning of OO is lost. Originally, OO meant to simulate the world around us, by transferring the concepts of the real world to the computer. For example, a sales system could have a customer object, a product object, a purchase object. Objects were objects; objects where not classified into hardcoded categories called 'classes'.

The reason the original meaning of OO is lost is technical limitations: real message passing was slow, and therefore C++ and then Java chosen multiple inheritance/interfaces. The technical limitations were not real, but perceived: C/C++/Java gives you a false sense of security with their static type systems...but if you code a little with Smalltalk or LISP you will see that static typing gives you very little, actually, while complicating things greatly.

Achilleas Margaritis

Posts: 674
Nickname: achilleas
Registered: Feb, 2005

Re: Gavin King: In Defence of the RDBMS

Posted: May 30, 2007 3:23 AM

> > > This is why a lot of OO programmers cry out for an OO
> > > database, simply to cover up their mistakes. They
> want
> > > something into which they can drop their badly
> designed
> > > objects instead of having to map to a properly
> > normalised
> > > structure.
> >
> > That's not true. You have to normalize the objects just
> > like you normalize the database. Normalization is not a
> > function of database implementation, but a fundamental
> > property of information organization.
>
> Then how come the structure of these "normalised" objects
> differs so much from the structure of the normalised
> database? If the two structures were the same then there
> would be absolutely no need for OR mappers to deal with
> the differences.

It does not differ at all, at least in my designs. Let's say we have a sales system: customers, sales, purchases. I would make 3 classes:

class Customer {
    string firstName;
    string lastName;
}
 
class Product {
    string name;
    int code;
    int price;
}
 
class Purchase {
    Customer customer;
    Product product;
    int amount;
}

The class 'Purchase' reflects the relationship between customers and products.

The real benefit of using DB4O is that it's much easier to use. For example, to store a list of purchases in the DB, I do:

for_each(Purchase p : purchases) db.put(p);

whereas with SQL I would have to do the following:

for(Purchase p : purchases) {
    PreparedStatement stm = connection.getPreparedStatement("INSERT INTO PURCHASES CUSTOMER PRODUCT AMOUNT VALUES ?, ?, ?");
    stm.setInt(1, p.customers.id);
    stm.setString(2, p.products.id);
    stm.setint(2, p.products.amount);
    stm.execute();
}

It's just so much easier with DB4O, it is ridiculous.

For example, if you want to put a field 'discount', you do the following:

class Purchase {
    Customer customer;
    Product product;
    int amount;
    int discount;
}

The rest of the code remains the same.

With Hibernate, I have to:

1) update the database.
2) update the XML Hibernate schema.
3) compile the XML hibernate scheme to update the Java classes.

With SQL, I have to:

1) update the SQL code.
2) run the application to make sure the new SQL is appropriately coded, and that I have not messed up Java's prepared statements.

I will say it again: it's just so much easier with DB4O, it is ridiculous.

Achilleas Margaritis

Posts: 674
Nickname: achilleas
Registered: Feb, 2005

Re: Gavin King: In Defence of the RDBMS

Posted: May 30, 2007 3:29 AM

> > > > Some (OK, a lot) of OO programmers dislike my
> > approach
> > > > because it is different from what they have been
> > > > taught. One table per class? No real OO
> > > > programmer would do that! It is not "pure" enough!
> > > > That's all BS as far as I am concerned. My approach
> > > > works, and works well, and knocks the spots off
> many
> > > > other methods I have seen.
> > >
> > > It seems to me that this only works if the programmer
> > has
> > > control of the database schema.
> >
> > Correct. I have given up working with other people's
> > second rate application designs with 3rd rate database
> > designs, so nowadays I only work on applications where
> I
> > have total control over everything. That means new
> > applications (which I design), new databases (which I
> > design) using a RAD framework (which I designed and
> > built).
>
> You must be every employer's dream. Do you bring this up
> in interviews?
>

It's not a big deal to normalize a schema: all that is needed is an application which takes the data from one database, which are unnormalized, and puts it in a new database, which is normalized. And it can happen while a company does not work, i.e. at night, at weekends, at public holidays.

Personally, I prefer to migrate the data to a better schema rather than continue work with a bad schema. I think that's beneficial, in the long run, for an enterprise, to get rid of the old things that hinder its development (things here refer to applications/data).

Flat View: This topic has 195 replies on 14 pages [ « | 1 2 3 4 5 6 7 8 | » ]

Previous Topic

Next Topic