I''d like to ask the rationale behind the constraint ActiveRecord puts on table IDs. If I understood it correctly ActiveRecord needs an ID for every table to work, otherwise it will complain for the lack of table_id_seq (in Postgres). Is it correct ? I''d say that it''s not a good choice from a DBA point of view, but first of all I''d like to know if I can disable this behaviour. HAND, ngw -- checking for life_signs in -lKenny... no Oh my god, make (1) killed Kenny ! You, bastards ! nicholas_wieland-at-yahoo-dot-it
On Tue, 11 Jan 2005 10:00:47 +0100, Nicholas Wieland <nicholas_wieland-whZMOeQn8C0@public.gmane.org> wrote:> I''d like to ask the rationale behind the constraint ActiveRecord puts on > table IDs. If I understood it correctly ActiveRecord needs an ID for > every table to work, otherwise it will complain for the lack of > table_id_seq (in Postgres). Is it correct ? > I''d say that it''s not a good choice from a DBA point of view, but first > of all I''d like to know if I can disable this behaviour. > > HAND, > ngwWhy is it bad to have an id for each record?
To answer the original poster, the feature can''t be disabled, but it can be bypassed. If you pass in the ID yourself, the adapter will simply return that ID.> Why is it bad to have an id for each record?It isn''t bad to have an "ID" on each table. But for me, why do I have to have an integer ID on each table vs. a composite primary key that the DBA is going to want to use. I''ve run into a few cases where adding the "required" id column isn''t what I want to do. Especially on child tables that can''t exist without the parent. Why should they have an independent ID when it will never be used? I''ve got a 4 or 8 byte integer that isn''t going to get used. Not only that but since it is the primary key, I also have an index that isn''t going to get used. On large tables this becomes an issue. With that said, I won''t give up the productivity gains I get from Rails just because I don''t like the primary key constraints they place on me. And it is all subjective. I like composite primary keys. Other people like 1 column primary keys. But this probably has to do with the logical data modeling I''ve done in the past. -- Justin Rudd http://seagecko.org/thoughts/
* Justin Rudd (justin.rudd-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org) [050111 13:36]:> I''ve run into a few cases where adding the "required" id column isn''t > what I want to do. Especially on child tables that can''t exist > without the parent. Why should they have an independent ID when it > will never be used? I''ve got a 4 or 8 byte integer that isn''t going > to get used. Not only that but since it is the primary key, I also > have an index that isn''t going to get used. On large tables this > becomes an issue.I wouldn''t discard concerns over space-efficiency out of hand (because this sort of attention to detail generally leads to more robust and scalable end products), but with storage prices -- even in the realm of multi-terabyte SCSI RAID arrays -- dropping in cost systematically over the past decades I find myself less and less concerned with 4-8 bytes per table row these days. Even though this extra column data often ends up on the wire over the application<->database socket it''s still typically not worth spending a lot of resources on minimizing (how often does this overhead really show up in profiling?). Generally LAN transmission costs, RAM costs, and CPU costs are dropping so steadily that the bytes on the wire are just so little noise in the profiling signal. For me, if the tradeoff is between an n% increase in storage and transmission overhead, versus an m% decrease in development time (=cost) and later maintenance cost, I''ll worry about the m% well before the n%. I don''t have solid numbers, but my gut tells me that in this case (adding an id to every row) the n% is dwarfed by the m% when using Rails. Rick -- http://www.rickbradley.com MUPRN: 946 | for people >>to sort through.. random email haiku | in excess of messages | a day on avg.
- Joe Van Dyk :> On Tue, 11 Jan 2005 10:00:47 +0100, Nicholas Wieland > <nicholas_wieland-whZMOeQn8C0@public.gmane.org> wrote: > > I''d like to ask the rationale behind the constraint ActiveRecord puts on > > table IDs. If I understood it correctly ActiveRecord needs an ID for > > every table to work, otherwise it will complain for the lack of > > table_id_seq (in Postgres). Is it correct ? > > I''d say that it''s not a good choice from a DBA point of view, but first > > of all I''d like to know if I can disable this behaviour. > > > > HAND, > > ngw > > Why is it bad to have an id for each record?First two I can think of: 1) Redundancy: an ID isn''t required for every table, when you have a big amount of rows you''re throwing away a lot of space... for nothing. 2) Putting a constraint on the DB schema means that if I have an application written in another language I must adapt my correct and running DB to use Rails... if I have my website on LAMP (for example) and I want to use Rails for whatever reason, I can''t just plug rails and develop my app, I have to modify my DB. 3) One of the best things of DBs is data independency, you can use the same DB for every application that relies on that data, an application should _never_ ask the DBA to adapt the schema to the platform, because data (DB schema) never changes, procedures on it always :) HAND, ngw -- checking for life_signs in -lKenny... no Oh my god, make (1) killed Kenny ! You, bastards ! nicholas_wieland-at-yahoo-dot-it ______________________________________________________________________ Yahoo! Mail: 6MB di spazio gratuito, 30MB per i tuoi allegati, l''antivirus, il filtro Anti-spam http://it.yahoo.com/mail_it/foot/?http://it.mail.yahoo.com/
> > 2) Putting a constraint on the DB schema means that if I have an > application written in another language I must adapt my correct and > running DB to use Rails... if I have my website on LAMP (for example) > and I want to use Rails for whatever reason, I can''t just plug rails > and > develop my app, I have to modify my DB. > 3) One of the best things of DBs is data independency, you can > use the same DB for every application that relies on > that data, an application should _never_ ask the DBA to adapt the > schema > to the platform, because data (DB schema) never changes, procedures on > it always :)well, i disagree here. rails maps a object schema to the db. very closely. there are ways to tweak it, different table names than class names. but after all there is some kind of dependency. to say that data never changes and to seperate procedures from it sounds not very object oriented at all ; ) i''m curious though, how often do you use use rails AND lamp for the same db schema? how often do you actually use the same db for multiple platforms?
One example will be we have both rich client (fat client) and a web client for the same database server. The web client is through apache + rails + MYSQL). The fat client can be QT, Visual Basic or any GUI toolkit + MySQL. chong -----Original Message----- From: rails-bounces-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org [mailto:rails-bounces-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org] On Behalf Of Florian Weber Sent: Tuesday, January 11, 2005 3:57 PM To: rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org; Nicholas Wieland Subject: Re: [Rails] The need of IDs in ActiveRecord> > 2) Putting a constraint on the DB schema means that if I have an > application written in another language I must adapt my correct and > running DB to use Rails... if I have my website on LAMP (for example) > and I want to use Rails for whatever reason, I can''t just plug rails > and > develop my app, I have to modify my DB. > 3) One of the best things of DBs is data independency, you can > use the same DB for every application that relies on > that data, an application should _never_ ask the DBA to adapt the > schema > to the platform, because data (DB schema) never changes, procedures on > it always :)well, i disagree here. rails maps a object schema to the db. very closely. there are ways to tweak it, different table names than class names. but after all there is some kind of dependency. to say that data never changes and to seperate procedures from it sounds not very object oriented at all ; ) i''m curious though, how often do you use use rails AND lamp for the same db schema? how often do you actually use the same db for multiple platforms? _______________________________________________ Rails mailing list Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org http://lists.rubyonrails.org/mailman/listinfo/rails
- Florian Weber :> >2) Putting a constraint on the DB schema means that if I have an > >application written in another language I must adapt my correct and > >running DB to use Rails... if I have my website on LAMP (for example) > >and I want to use Rails for whatever reason, I can''t just plug rails > >and > >develop my app, I have to modify my DB. > >3) One of the best things of DBs is data independency, you can > >use the same DB for every application that relies on > >that data, an application should _never_ ask the DBA to adapt the > >schema > >to the platform, because data (DB schema) never changes, procedures on > >it always :) > > well, i disagree here. rails maps a object schema to the db. very > closely.Yes, I think that Active Record is a great piece of software, because it respects the relational data model without assuming too much. I''m at 60% a DBA and 40% a developer, I''ve always said that ORMs are the best approach possible in an OO environment to data, instead of OODBs.> to say that data never changes and to seperate procedures from it sounds > not very object oriented at all ; )Well, in fact OO development IMHO is an approach to programming, not a data model. AFAIK an object is data + procedures. Using a model is OO, data has nothing to do with it IMVHO. I attach behaviuor to data through the model, I change/delete/foobar data through my model, if the schema is correct you''ll never change it.> i''m curious though, how often do you use use rails AND lamp for the > same db schema?Well, I don''t use LAMP, it was just an example, I prefer FreeBSD and PostgreSQL :) Never used Rails in production, I''m learning, I''ve used Python a lot. But I''ve never changed my DB schema to adapt it to another application, if I had to change it the schema was wrong, it''s as simple. Data is data. An example: last year I''ve developed an e-commerce site and my customer had a CRM in production; of course he wanted me to integrate my work with what he was using. In a similar situation I simply can''t use rails, I''d have to modify what''s already in production. Now the e-commerce site "registers" customers on the DB, those data are manipulated by the employers inside the CRM, but customers can modify their data from the site. Same data, different "models". IMHO Rails is perfect for this, and this is why I''ve asked the rationale behind this constraint, because from my point of view it has a lot of (well hidden) drawbacks. HAND, ngw -- checking for life_signs in -lKenny... no Oh my god, make (1) killed Kenny ! You, bastards ! nicholas_wieland-at-yahoo-dot-it
> Yes, I think that Active Record is a great piece of software, because it > respects the relational data model without assuming too much. > I''m at 60% a DBA and 40% a developer, I''ve always said that ORMs are the > best approach possible in an OO environment to data, instead of OODBs.If a surrogate key isn''t what you want to use, then an ORM is probably not the right solution. The Object Oriented view of the world and the Relational view differ on the concept of identity. With a relational model, if the columns are identical, the two ''things'' are identical. So compare these two concepts a table : CREATE TABLE users ( first_name varchar(255), last_name varchar(255) ); and the following class class User attr_accessor :first_name, :last_name end With the table, there is no difference between two rows representing myself (an OO developer in New Zealand) and the other michael koziarski (some aol subscriber in michigan). This is different in an OO situation: irb(main):006:0> u1 = User.new irb(main):007:0> u1.first_name = "Michael" irb(main):008:0> u1.last_name = "Koziarski" irb(main):009:0> u2 = User.new irb(main):010:0> u2.first_name = "Michael" irb(main):011:0> u2.last_name = "Koziarski" irb(main):012:0> u1 == u2 => false the values are the same, but they''re aren''t "the same object". Objects inherently *have* identity. They just do. The values aren''t relevant to this identity. So when we save an object in an RDBMS, we need some representation of the identity that isn''t tied to its values. Hence the ''auto_increment''ing surrogate keys.> > to say that data never changes and to seperate procedures from it sounds > > not very object oriented at all ; )It''s not, it''s a data modelers approach, which is fine. But you''ll have difficulty when dealing with an OO system.> Well, in fact OO development IMHO is an approach to programming, not a > data model. AFAIK an object is data + procedures. > Using a model is OO, data has nothing to do with it IMVHO. I attach > behaviuor to data through the model, I change/delete/foobar data through > my model, if the schema is correct you''ll never change it.Here''s where we''ll disagree. The domain model you build maps to the business processes your application supports. The schema is just where your objects go to sleep, nothing but a store. There should never be behaviour in your classes that''s inconsistent with your business processes. If there is, you change your classes. I came to this position because I''ve been burned many times by the "here''s the DB, have at it" approach to sharing data. You either end up with hideously complicated schemas that are so abstract that they suit noone in particular. Parties have Arrangements instead of Customers with Accounts. The other end of the schema is that it''s so specific to one application that your ''sharing'' involves so many special cases that it''s irrelevant to other apps. i..e Customers have Accounts rather than Clients having Policies.> > i''m curious though, how often do you use use rails AND lamp for the > > same db schema? > > Well, I don''t use LAMP, it was just an example, I prefer FreeBSD and > PostgreSQL :) > Never used Rails in production, I''m learning, I''ve used Python a lot. > But I''ve never changed my DB schema to adapt it to another application, > if I had to change it the schema was wrong, it''s as simple. Data is > data. > > An example: last year I''ve developed an e-commerce site and my customer > had a CRM in production; of course he wanted me to integrate my work > with what he was using. In a similar situation I simply can''t use rails, > I''d have to modify what''s already in production. Now the e-commerce site > "registers" customers on the DB, those data are manipulated by the > employers inside the CRM, but customers can modify their data from the > site. Same data, different "models". > > IMHO Rails is perfect for this, and this is why I''ve asked the rationale > behind this constraint, because from my point of view it has a lot of > (well hidden) drawbacks.Remember that you can replace ActiveRecord with your own persistence implementation, and that would be my advice here. You can include a lot of the active record functionality, like validations by including the modules. it should be relatively easy as they''re designed to stand alone. When it comes down to it, Active Record (not rails) *does* make assumptions about your schema and fighting them may be more trouble than it''s worth. If you view your classes as very thin layers around your data, I''d build just that. A thin layer specific to your database and use rails to manipulate it. Writing up something like this would make a great document for people who want to get the benefits of the view and controller aspects of rails, but want to work with existing schemas. -- Cheers Koz
Justin Rudd wrote:> Especially on child tables that can''t exist > without the parent. Why should they have an independent ID when it > will never be used?Rails doesn''t really support child tables anyway (yet). To do a child relationship it has a "type" field. So this type of data structure cannot be used in Rails anyway. Eric _______________________________________________ Rails mailing list Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org http://lists.rubyonrails.org/mailman/listinfo/rails
On Tue, 11 Jan 2005 19:21:09 -0500, Eric Anderson <eric-ANzg6odk14w@public.gmane.org> wrote:> Justin Rudd wrote: > > Especially on child tables that can''t exist > > without the parent. Why should they have an independent ID when it > > will never be used? > > Rails doesn''t really support child tables anyway (yet). To do a child > relationship it has a "type" field. So this type of data structure > cannot be used in Rails anyway.What is a child table?
Nicholas Wieland wrote:> 2) Putting a constraint on the DB schema means that if I have an > application written in another language I must adapt my correct and > running DB to use Rails... if I have my website on LAMP (for example) > and I want to use Rails for whatever reason, I can''t just plug rails and > develop my app, I have to modify my DB. > 3) One of the best things of DBs is data independency, you can > use the same DB for every application that relies on > that data, an application should _never_ ask the DBA to adapt the schema > to the platform, because data (DB schema) never changes, procedures on > it always :)It seems to me that this is the way Rails reduces the amount of code compared to the various ORM solutions that require mapping files. Since Rails assumes a certain data structure it can capitalize on that commonality and reduce the amount of code you have to write. If you want to support wildly varying database schemas then you end up resorting to various mapping methodologies and even custom data objects. Obviously through options (such as :finder_sql, table name prefixes and suffixes and others) we can expand the number of different database designs Rails can support without much coding. But if a database design is too far out of the standard design Rails assumes, then ActiveRecord will not be able to do the ORM because it requires something more complex (and will require more code). Avoiding complexity and lots of code seems to be a design goal of ActiveRecord so something else will be a better tool. Obviously this does create problems where multiple applications are using a database. You hope the database design is one Rails can grok, but if it is not then another ORM might be in order. The good news is that the design Rails supports is common and recommended. Therefore many databases conform with perhaps only a small amount of tweaking on either the code or database side. Just my two cents, Eric _______________________________________________ Rails mailing list Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org http://lists.rubyonrails.org/mailman/listinfo/rails
Florian Weber wrote:> i''m curious though, how often do you use use rails AND lamp for the > same db schema? > > how often do you actually use the same db for multiple platforms?I have found that when developing application (web-based, server-side or desktop-GUI) I often have to interface with an existing database platform. In the enterprise, customers have often invested a good amount of time and money into a system and they want their new systems to integrate with the old system in order to continue to reap the benefits of their investment into the old system. It seems to me that what would be ideal is two have two different ORM libraries in Rails. One is the current ActiveRecord which assumes a certain database design so that it can reduce the amount of coding. The other uses various mapping files and custom code blocks to map the OO model to the relational model. That way if you are interfacing with new RDMBS data structures you can develop them to use a Rails-friendly schema. Or if you are interfacing with a existing RDBMS system that already follows the Rails schema closely you can use ActiveRecord. But if you have a completely different schema from what Rails assumes you could use a combination of mapping files and custom code to allow access to the legacy system. If I can ever start getting Rails in the enterprise then that is what I will be trying to develop (or adapt from an existing library). An ORM that is interface compatible with ActiveRecord (so it feels comfortable), but allows for more complex and custom backend schemas. This way you get the best of both worlds. You can use ActiveRecord for the easy cases and the complex system for the hard cases. _______________________________________________ Rails mailing list Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org http://lists.rubyonrails.org/mailman/listinfo/rails
Joe Van Dyk wrote:> What is a child table?CREATE TABLE people ( id INT PRIMARY KEY AUTO_INCREMENT, first_name VARCHAR(30) NOT NULL, last_name VARCHAR(40) NOT NULL ) CREATE TABLE employees ( person INT UNIQUE NOT NULL, department VARCHAR(255) NOT NULL, boss INT NOT NULL, FOREIGN KEY (person) REFERENCES people.id FOREIGN KEY (boss) REFERENCES people.id ) CREATE TABLE clients ( person INT UNIQUE NOT NULL, company VARCHAR(255) NOT NULL, FOREIGN KEY (person) REFERENCES people.id ) In this case employee and client are child tables of people. For every record in employees or clients you will have a record in people, but you may have records in people that are not employees or clients (they could be vendors, or something else entirely). So: people / \ / \ / \ employees clients Eric _______________________________________________ Rails mailing list Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org http://lists.rubyonrails.org/mailman/listinfo/rails
> Rails doesn''t really support child tables anyway (yet). To do a child > relationship it has a "type" field. So this type of data structure > cannot be used in Rails anyway.That''s Subclassing/inheritance more than parent child relationship. A child table in my mind (and in the business process world) is one that is depending on another table. To (over)use the purchase order... A PO is the parent. It has a primary key like PO Number. A PO Line Item is a child of the PO. It has a composite primary key PO Number, Line Item Number. Therefore a PO Line Item can''t exist without a valid PO (assuming foreign keys constraints are used). The "type" column facilitates inheritance like an Employee is a Person. -- Justin Rudd http://seagecko.org/thoughts/
[snip people, employees, clients SQL]> In this case employee and client are child tables of people. For every > record in employees or clients you will have a record in people, but you > may have records in people that are not employees or clients (they could > be vendors, or something else entirely).That''s inheritance, not a parent/child relationship. In your example DB, an employee can''t exist without a person entry but that is because it inherits some attributes from the person table. But that really isn''t parent/child in my mind. A parent table is one that lends its identity to a child to help uniquely identify the child. I used an example of a PO and a PO Line item in another e-mail. The PO Line Item is a child of the PO because its primary key is a the PO Number and the Line Item number. -- Justin Rudd http://seagecko.org/thoughts/
[snip users table]> With the table, there is no difference between two rows representing > myself (an OO developer in New Zealand) and the other michael > koziarski (some aol subscriber in michigan).Only if the primay key is [first_name, last_name]. If the key isn''t [first_name, last_name] then each row is a unique instance even if they all have the same values.> This is different in an OO situation: >[snip IRB]> > the values are the same, but they''re aren''t "the same object". > Objects inherently *have* identity. They just do. The values aren''t > relevant to this identity.Using your example, what should the following output? u1 = User.find(1) u2 = User.find(1) u1 == u2 Today it will output ''false''. But really they are the same because the primary key is the same. So who is right? Ruby or the DB? I contend the DB is the correct. Typically in most ORM solutions, the equality operator is overloaded to check primary keys for equality. This allows the above to work.> Here''s where we''ll disagree. The domain model you build maps to the > business processes your application supports. The schema is just > where your objects go to sleep, nothing but a store.I agree and disagree with this. I agree that the domain model maps to your business processes. But I disagee that your schema/DB is just where the objects go to sleep. The DB and the data in it is more important than the business processes. Those processes will change based on the data. You will write tons of reports and ad hoc queries to give business users data that they can use to modify the processes. After they modify the processes, the DB/schema will more than likely stay backwards compatible. You might add a column, but hardly ever remove. Especially when you have many GBs of data. Developers are a very small minority of the users of the data. They want tables that map well to their objects. But that isn''t reality. Reality is that the data is for the business. And the business needs to be able to mine that data quickly. And that means having a stable schema that makes sense to the business. Not a schema that changes because you figured out a cooler way to implement an algorithm.> Remember that you can replace ActiveRecord with your own persistence > implementation, and that would be my advice here.Which is what I''m playing with right now. I''m using Needle as the container of my "models". Some of my components in Needle use ActiveRecord, but not all of them. Some of the components use a View for querying and the underlying tables for inserts. I haven''t tried using the validation framework in my components yet though. Of course, I could be jaded from 10+ years of writing software for businesses that just see software as a means to an end, not the end itself. -- Justin Rudd http://seagecko.org/thoughts/
> Using your example, what should the following output? > > u1 = User.find(1) > u2 = User.find(1) > u1 == u2 > > Today it will output ''false''.No it won''t: Feed.find(1) == Feed.find(1) => true The surrogate key is the serialized form of the objects inherent identity.> I agree and disagree with this. I agree that the domain model maps to > your business processes. But I disagee that your schema/DB is just > where the objects go to sleep. The DB and the data in it is more > important than the business processes. > >Those processes will change > based on the data. You will write tons of reports and ad hoc queries > to give business users data that they can use to modify the processes. > After they modify the processes, the DB/schema will more than likely > stay backwards compatible. You might add a column, but hardly ever > remove. Especially when you have many GBs of data.That depends on the type of application you''re building really. Data first is one valid approach to application development, it''s just not one I subscribe to. I personally try to get the objects right, and get business buy in on the model. Then encapsulate the data so that changing it isn''t that big a deal. Even many GBs of data can be updated overnight.> Developers are a very small minority of the users of the data. They > want tables that map well to their objects. But that isn''t reality. > Reality is that the data is for the business. And the business needs > to be able to mine that data quickly. And that means having a stable > schema that makes sense to the business. Not a schema that changes > because you figured out a cooler way to implement an algorithm.They''re not our objects, they''re the business'' objects as they map their procedures and their processes and when those processes change, so should the objects. Either way, our views are two ends of a continuum, balance is key. Both approaches are valid and it depends on your requirements, constraints and your personal biases. ;) The key point I was trying to make, before my down-with-data rant took over is that ActiveRecord leans more towards my end of this continuum. But Rails itself doesn''t.> > Remember that you can replace ActiveRecord with your own persistence > > implementation, and that would be my advice here. > > Which is what I''m playing with right now. I''m using Needle as the > container of my "models". Some of my components in Needle use > ActiveRecord, but not all of them. Some of the components use a View > for querying and the underlying tables for inserts.I''d be really interested in seeing a writeup of this.> I haven''t tried using the validation framework in my components yet though. > > Of course, I could be jaded from 10+ years of writing software for > businesses that just see software as a means to an end, not the end > itself.I work for a bank, banks win when it comes to crazy approaches to software.> -- > Justin Rudd > http://seagecko.org/thoughts/ >-- Cheers Koz
So how do you call the relation in which you have, for example, books and exemplars of those books? For each book, you will have many different exemplars of it, but all of them will have the same title, ISBN, author, number of pages .... and in turn, each exemplar will have a different owner, status, sell price, location and so on. I model this as 2 tables, books and exemplars, where a book has_many exemplars and an exemplar belongs_to (or is it has_one) book. The common data is on the book table, while individual data is on exemplar. Also, books can exist on its own (for example, a book in a wishlist, you are referring to the ''prototype'' of the book, not to any concrete exemplar) I am really undecided towards inheritance or association here, and would gladly welcome other opinions on the matter. cheers Victor Justin Rudd wrote:> > > That''s Subclassing/inheritance more than parent child relationship. A > child table in my mind (and in the business process world) is one that > is depending on another table. To (over)use the purchase order... > > A PO is the parent. It has a primary key like PO Number. > A PO Line Item is a child of the PO. It has a composite primary key > PO Number, Line Item Number. Therefore a PO Line Item can''t exist > without a valid PO (assuming foreign keys constraints are used). > > The "type" column facilitates inheritance like an Employee is a Person. >
- Michael Koziarski :> > Yes, I think that Active Record is a great piece of software, because it > > respects the relational data model without assuming too much. > > I''m at 60% a DBA and 40% a developer, I''ve always said that ORMs are the > > best approach possible in an OO environment to data, instead of OODBs. > > If a surrogate key isn''t what you want to use, then an ORM is > probably not the right solution. The Object Oriented view of the > world and the Relational view differ on the concept of identity. > > With a relational model, if the columns are identical, the two > ''things'' are identical. So compare these two concepts a table : > > CREATE TABLE users ( > first_name varchar(255), > last_name varchar(255) > ); > > and the following class > > class User > attr_accessor :first_name, :last_name > end > > With the table, there is no difference between two rows representing > myself (an OO developer in New Zealand) and the other michael > koziarski (some aol subscriber in michigan). This is different in an > OO situation: > > irb(main):006:0> u1 = User.new > irb(main):007:0> u1.first_name = "Michael" > irb(main):008:0> u1.last_name = "Koziarski" > irb(main):009:0> u2 = User.new > irb(main):010:0> u2.first_name = "Michael" > irb(main):011:0> u2.last_name = "Koziarski" > irb(main):012:0> u1 == u2 > => false > > the values are the same, but they''re aren''t "the same object". > Objects inherently *have* identity. They just do. The values aren''t > relevant to this identity. > > So when we save an object in an RDBMS, we need some representation of > the identity that isn''t tied to its values. Hence the > ''auto_increment''ing surrogate keys.foo=# insert into users values (''Nicholas'', ''Wieland''); INSERT 17724 1 foo=# insert into users values (''Nicholas'', ''Wieland''); INSERT 17725 1 foo=# select * from users; first_name | last_name ------------+----------- Nicholas | Wieland Nicholas | Wieland (2 righe) foo=# select OID from users; oid ------- 17724 17725 (2 righe) :) BTW, I''m not saying to never use an ID, this would be wrong as requiring it, but if you have different data you have to model the schema accordingly. In this case, if you can''t identify your data in any other way, adding an ID is totally correct. For example: how do I use ActiveRecord if I have a table that has a FK to a numerical id in another in a one to one relationship ? Do I have to add _another_ numerical id ?> > > to say that data never changes and to seperate procedures from it sounds > > > not very object oriented at all ; ) > > It''s not, it''s a data modelers approach, which is fine. But you''ll > have difficulty when dealing with an OO system.Never had one, but maybe it''s just me.> > Well, in fact OO development IMHO is an approach to programming, not a > > data model. AFAIK an object is data + procedures. > > Using a model is OO, data has nothing to do with it IMVHO. I attach > > behaviuor to data through the model, I change/delete/foobar data through > > my model, if the schema is correct you''ll never change it. > > Here''s where we''ll disagree. The domain model you build maps to the > business processes your application supports. The schema is just > where your objects go to sleep, nothing but a store. There should > never be behaviour in your classes that''s inconsistent with your > business processes. If there is, you change your classes.I can''t see where you disagree ... :) DBs _are_ just a store, nothing else. Yes, you change your class, not the DB.> I came to this position because I''ve been burned many times by the > "here''s the DB, have at it" approach to sharing data. You either end > up with hideously complicated schemas that are so abstract that they > suit noone in particular. Parties have Arrangements instead of > Customers with Accounts.Well, sometimes it''s the only way to represent data.> When it comes down to it, Active Record (not rails) *does* make > assumptions about your schema and fighting them may be more trouble > than it''s worth. If you view your classes as very thin layers around > your data, I''d build just that. A thin layer specific to your > database and use rails to manipulate it.I see my classes as a way to use my data, nothing else. HAND, ngw -- checking for life_signs in -lKenny... no Oh my god, make (1) killed Kenny ! You, bastards ! nicholas_wieland-at-yahoo-dot-it
- Eric Anderson :> It seems to me that this is the way Rails reduces the amount of code > compared to the various ORM solutions that require mapping files. Since > Rails assumes a certain data structure it can capitalize on that > commonality and reduce the amount of code you have to write. If you want > to support wildly varying database schemas then you end up resorting to > various mapping methodologies and even custom data objects. > > Obviously through options (such as :finder_sql, table name prefixes and > suffixes and others) we can expand the number of different database > designs Rails can support without much coding. But if a database design > is too far out of the standard design Rails assumes, then ActiveRecord > will not be able to do the ORM because it requires something more > complex (and will require more code). Avoiding complexity and lots of > code seems to be a design goal of ActiveRecord so something else will be > a better tool.Yes, it avoids complexity in code adding redundancy on the DB. Another problem will be to convince my DBA to change his normalized schema to fit Rails ("HA! Programmers! Thou shalt die!" :)) IMHO if ActiveRecord "inspects" the table and maps only what it can ... If the table has an ID use it, if it hasn''t map your schema with your model. Is this stupid ? People can choose instead of using another ORM... for an ID. HAND, ngw -- checking for life_signs in -lKenny... no Oh my god, make (1) killed Kenny ! You, bastards ! nicholas_wieland-at-yahoo-dot-it
>> to say that data never changes and to seperate procedures from it >> sounds >> not very object oriented at all ; ) > > Well, in fact OO development IMHO is an approach to programming, not a > data model. AFAIK an object is data + procedures. > Using a model is OO, data has nothing to do with it IMVHO. I attach > behaviuor to data through the model, I change/delete/foobar data > through > my model, if the schema is correct you''ll never change it.what about design? oo is not just some development way. saying that a object is data + procedures is imho a complete wrong view of things. that would be just the same old procedural style with a different name..
Justin Rudd wrote:> That''s inheritance, not a parent/child relationship.[...snip...]> A parent table is one that lends its identity to a child to help > uniquely identify the child. I used an example of a PO and a PO Line > item in another e-mail. The PO Line Item is a child of the PO because > its primary key is a the PO Number and the Line Item number.I guess this is just difference in definition. Usually when I think of inheritance I think of it as a parent/child relationship. The superclass is the parent, the subclass is the child. For your PO example I see those as two different objects. The PO Line Item is related to and dependent on the PO, but it is still it''s own object. Like I said, just a difference in definition. Eric _______________________________________________ Rails mailing list Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org http://lists.rubyonrails.org/mailman/listinfo/rails
- Florian Weber :> >>to say that data never changes and to seperate procedures from it > >>sounds > >>not very object oriented at all ; ) > > > >Well, in fact OO development IMHO is an approach to programming, not a > >data model. AFAIK an object is data + procedures. > >Using a model is OO, data has nothing to do with it IMVHO. I attach > >behaviuor to data through the model, I change/delete/foobar data > >through > >my model, if the schema is correct you''ll never change it. > > what about design? oo is not just some development way. > > saying that a object is data + procedures is imho a complete wrong > view of things. that would be just the same old procedural style with > a different name..Ehm... "procedural" is about procedures, data and procedures aren''t packed together in any way ... A "function" takes data and trosforms it according to the function body, the "procedure". An object in fact is a logical union of data and procedures _on that data_; this is what I''ve studied and how I think about OO: OO design is just a part of the same approach, as procedural design is a part of procedural programming. But: I don''t pretend to teach anything to anyone, if anybody got that impression I''m so sorry, please excuse me ... This is why I''ve asked the rationale behind it, I want to learn and to be convinced that the Rails way is the right one. The problem is that convincing someone that the relational model is wrong because it''s not productive for the programmer is very hard, because the problem is here, having an ID for every table means that the schema isn''t normalized ... means that as a programmer I have to influence the DBA on his design: what would you answer to a DBA that wants to impose a design on your application for using his fooDB instead of the usual barDB ? HAND, ngw -- checking for life_signs in -lKenny... no Oh my god, make (1) killed Kenny ! You, bastards ! nicholas_wieland-at-yahoo-dot-it
> This is why I''ve asked the rationale behind it, I want to learn and to > be convinced that the Rails way is the right one. The problem is that > convincing someone that the relational model is wrong because it''s not > productive for the programmer is very hard, because the problem is > here, > having an ID for every table means that the schema isn''t normalized ... > means that as a programmer I have to influence the DBA on his design: > what would you answer to a DBA that wants to impose a design on your > application for using his fooDB instead of the usual barDB ?There''s no need to convince anyone that "the relational model is wrong". Propose it as a trade-off: If we follow these conventions, make these sacrifices to the purity of the relational model, we''re able to develop and deliver software faster. That should be a shared goal, so hopefully not too hard to agree upon. -- David Heinemeier Hansson, http://www.basecamphq.com/ -- Web-based Project Management http://www.rubyonrails.org/ -- Web-application framework for Ruby http://macromates.com/ -- TextMate: Code and markup editor (OS X) http://www.loudthinking.com/ -- Broadcasting Brain
> I guess this is just difference in definition. Usually when I think of > inheritance I think of it as a parent/child relationship. The superclass > is the parent, the subclass is the child.We agree to disagree :) Because to me a parent child relationship is one where a child can''t possibly exist without the parent. PO Line Item can''t exist without the PO. In an inheritance situation, a child/subclass can''t exist without the definition of the parent/superclass, but it can exist without a parent/superclass being created first. So I can see how you would describe that situation as parent/child. Because when you create the child/subclass, it implicitly creates a parent/superclass. But I don''t see it that way. I''m not creating a parent/superclass, I''m creating a child/subclass that can act like a parent/superclass.> Like I said, just a difference in definition.It''s what makes the world go round. -- Justin Rudd http://seagecko.org/thoughts/
> This is why I''ve asked the rationale behind it, I want to learn and to > be convinced that the Rails way is the right one. The problem is that > convincing someone that the relational model is wrong because it''s not > productive for the programmer is very hard, because the problem is here, > having an ID for every table means that the schema isn''t normalized ... > means that as a programmer I have to influence the DBA on his design: > what would you answer to a DBA that wants to impose a design on your > application for using his fooDB instead of the usual barDB ?I think I''ve made it pretty clear that I like composite keys as primary keys because they tend to model life more closely. I get that from working with many business and data modeling people. But I won''t hesitate to use a single ID as the primary key if the real primary key is unfriendly. One one project I worked on we had a table that could only be uniquely identified by 6 columns. And that table was a parent to 7 other tables. So all 7 of those tables had to have those 6 columns in them. We add 1 column to the table that was just a single 8 byte ID. Saved us a lot of headaches. Is it denormalized? Yep. But the overall performance was much better because we didn''t have 16 copies (8 for the tables and then 8 for the indexes) of those 6 columns sitting around. I agree with David on this one. It''s all about tradeoffs. You will win some, you will lose some. The nice thing is that Action Pack (the controller and the view) are easy enough to use by themselves if you lose more than you win :) -- Justin Rudd http://seagecko.org/thoughts/
On Wed, 12 Jan 2005 10:26:39 -0800, Justin Rudd <justin.rudd-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:> > I guess this is just difference in definition. Usually when I think of > > inheritance I think of it as a parent/child relationship. The superclass > > is the parent, the subclass is the child. > > We agree to disagree :) Because to me a parent child relationship is > one where a child can''t possibly exist without the parent. PO Line > Item can''t exist without the PO. In an inheritance situation, a > child/subclass can''t exist without the definition of the > parent/superclass, but it can exist without a parent/superclass being > created first.The relationship you''re talking about here is aggregation, the little diamond arrow in the UML. It''s very different to inheritance, however, if you use the phrase ''parent/child'' it could mean either. Stupid english language ;)> So I can see how you would describe that situation as parent/child. > Because when you create the child/subclass, it implicitly creates a > parent/superclass. But I don''t see it that way. I''m not creating a > parent/superclass, I''m creating a child/subclass that can act like a > parent/superclass. > > > Like I said, just a difference in definition. > > It''s what makes the world go round. > > -- > Justin Rudd > http://seagecko.org/thoughts/ > _______________________________________________ > Rails mailing list > Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org > http://lists.rubyonrails.org/mailman/listinfo/rails >-- Cheers Koz