Loading ...
Sorry, an error occurred while loading the content.

Re: [XP] Database Refactor: Replace Named Columns with a Table of Generic Columns and Metadata

Expand Messages
  • Phlip
    ... Then call what I did a potentially good thing to do to databases . I should not have used the term normalization . ... If, for example, the values and
    Message 1 of 4 , Jan 11, 2013
      On Fri, Jan 11, 2013 at 4:59 AM, Francis Fish <francis@...> wrote:

      > Normalisation, as I understand it, is reducing things to third normal form.
      > i.e. http://en.wikipedia.org/wiki/Third_normal_form

      Then call what I did a "potentially good thing to do to databases". I
      should not have used the term "normalization".

      > You just seem to be eschewing nulls, which is laudable, and adding a *lot*
      > of complexity, which is not. Chris Date talks a lot about avoiding nulls
      > wherever you can because you end up with 3 value logic and that way lies
      > madness.

      If, for example, the values and labels, such as 'swallow_velocity',
      had each gone into their own separate table, then the result would be
      _more_ complex. Even if one then hid the complexity in a view.

      The root of my refactor is "roll up an unrolled loop." Like I said, we
      could also have rolled it up by making a list of fields, instead of
      records, to loop through.

      > In the Ruby example you are violating the "fat model, thin controller"
      > principle by putting the find_by logic in the view where it does not
      > belong, pushing this into the view just means you end up with stuff that's
      > brittle and very hard to test. Moving this into named methods on the model
      > class is what you should be doing, because you can do things like catch
      > exceptions (say a relationship is empty but you want to display a
      > meaningful default, it would be a nightmare to ram this in the view), and,
      > holy of holies, test it really easily.

      I said in a TODO comment to move the excess code to the model.

      > To test the view you'd have go into
      > a stubbing frenzy and it would be incredibly brittle.

      I wouldn't have a problem with testing that through the view, but of
      course the model comes first.

      > ActiveRecord also has a nice built in delegation system you can use if you
      > must go for this data model and keep it out of the view.

      And I was illustrating the actual refactor, not ActiveRecord. Yes it
      could wrap the leaf table.

      > There is also another separate discussion about how the now pervasive habit
      > of using synthetic id's as keys everywhere is a *bad* idea instead of the
      > true keys and other data that goes with them, but most ORM's aren't built
      > to do this so it's hard to do it right. But not doing it means it's really
      > easy to end up with orphaned or duplicate data unless you put in unique
      > indexes on the true keys and express the true relationships by defining
      > them in the underlying RDBMS.

      And I pointed out somewhere the metadata table could have been a real table.

      > I use AR because it's less work and everybody uses it, but it makes the
      > database nut in me cringe.

      Ah, that explains it.

      John Carter wrote:

      >> Normalised "null" free version...
      >> DROP TABLE IF EXISTS "favourite_color";
      >> CREATE TABLE "favourite_color" ("id" INTEGER PRIMARY KEY NOT NULL ,
      >> "color" TEXT NOT NULL );
      >> INSERT INTO "favourite_color" VALUES(1,'pink');


      oookay, if we are still on the "null rule", maybe a better rule is
      "sometimes you should replace several fields that are often all null,
      together, with a leaf table, whose entire record might not be there."

      >> A view to serve up _exactly_ what you had initially.
      >> CREATE VIEW "user_view" AS select

      Thanks but the idea was simplifying the code that non-database-nuts
      care about; the model & view.

    Your message has been successfully submitted and would be delivered to recipients shortly.