[eluser]kurucu[/eluser]
Question 2....
If you use a normally formed database structure, you tend to end up with a one-one relationship between models and tables. Right? (maybe wrong)
I have gone down this route, as it saves a lot of confusion and mess. In my model, one discussed briefly elsewhere, has a users table and a posts table.
If you wish to display a list of posts, and with each post the name and some other details about the user, how do you handle that? My thoughts are torn between:
- Joining the information, which seems to 'dirty' the posts table and mean that for other uses I have too much information in the array. Seems fast, but leaves me with more and more specific calls in my models that become unmanageable.
- get_posts, and then somewhere (controller? view?) attach a user object to each post. Slower, but maybe not too slow, but much cleaner and easier to reuse and follow.
- get_posts, and then build a user cache based on the unique users in that post list. Perhaps an optimisation of point 2.
What have/would you done/do? Any other suggestions?
[eluser]n0xie[/eluser]
I just use joins. It's what they exist for.
If you want to keep your models 'clean' and hide the underlying database structure, you could use an ORM.
[eluser]Johan André[/eluser]
I'd use joins too.
I would probably create a base model which handles the joins automatically too... Kindof ORM light... 
[eluser]jedd[/eluser]
[quote author="kurucu" date="1253809880"]
If you use a normally formed database structure, you tend to end up with a one-one relationship between models and tables. Right? (maybe wrong)
[/quote]
a) What is a normally formed database structure, in your opinion?
b) In my opinion, database form should not ineluctably lead you to a 1:1 relationship between models and tables.
To answer the rest of your question.
I agree that the range of approaches to this problem all have something ugly about them.
I tend to take the view that a model owns its collection of tables - and by this I mean that it has exclusive write access to those tables. Other models can read those tables, though, to their heart's content.
I'm unsure if this is a particularly elegant way of dealing with the problem, and I know that if a major structural change to the schema occurs that it'll involve a fair bit of effort.
I suspect that I should defer to simple lookups within each 'owning' model for each of the data that other models want to read - but at the moment that seems like more work and a similar degree of ugliness.
[eluser]kurucu[/eluser]
I did consider an ORM, I forgot to mention that. But then I hope that I gain efficiency and control where an ORM offers ease and simplicity.
[quote author="Johan André" date="1253810628"]
I’d use joins too.
I would probably create a base model which handles the joins automatically too… Kindof ORM light… smile[/quote]
You would do what and how? Automatically performs the joins for you? Can you provide some clues?
[quote author="jedd" date="1253810765"]
a) What is a normally formed database structure, in your opinion?[/quote]
Hmm. Tables only containing information related to themselves. Tables referring to other tables 1:1 or 1:n. Join tables for n:n...
[quote author="jedd" date="1253810765"]
b) In my opinion, database form should not ineluctably lead you to a 1:1 relationship between models and tables.[/quote]True, but I found having more knowledgeable models led to some complexity.
[quote author="jedd" date="1253810765"]
To answer the rest of your question.
I agree that the range of approaches to this problem all have something ugly about them.
I tend to take the view that a model owns its collection of tables - and by this I mean that it has exclusive write access to those tables. Other models can read those tables, though, to their heart’s content.[/quote]
Seems sound to me - I might inherit something along these lines.
It's this problem of 'ugly no matter what' that I guess I am asking about. Which is sufficiently pleasant looking that it doesn't break the CI mirror?
[eluser]jedd[/eluser]
If you can't be bothered previewing, then at least browse over your post after submitting it.
For reasons that aren't clear, quote tags require the date parameter.
Quote:Hmm. Tables only containing information related to themselves. Tables referring to other tables 1:1 or 1:n. Join tables for n:n...
I'm still somewhat bewildered here. Do you mean 3NF? 6NF?
Quote:Quote:b) In my opinion, database form should not ineluctably lead you to a 1:1 relationship between models and tables.
True, but I found having more knowledgeable models led to some complexity.
Complexity or volume?
I combine many tables - in one case upwards of twenty - into my models in order to avoid the complexity of inter-model communication (either directly or via a controller).
I accept that it necessarily gets larger, as a result, that what your average model might be - but OTOH I think it's smaller than the codebase would be if I separated everything out (one model per table, f.e.)
If there's a natural grouping of tables, then it'll be relatively straightforward (consequently predictable and sensible and not overly complex) to have that grouping handled by a model.
I accept that for many people the appeal of an ORM, or the apparent simplicity or elegance of a one model to one table approach works just as well.
[eluser]kurucu[/eluser]
I did preview it, twice, and couldn't get the quotes to work before running off to a meeting. The post is still legible, so I thought it wouldn't matter for now. Clearly not.
Having done some research - I mean 3NF.
Regarding the complexity over size question, I think more complex. The post model, in this instance, has to start returning information about the user who made the post. This means that there are a variety of functions which are specific to a certain view in the application. Ok. Granted, that means there is also more size, but certainly that's complexity and a level of specification which, for me, starts to pull away from the idea that models are agnostic.
Having said that, perhaps this is still me asking the original question.
Pondering more on what you said earlier regarding grouping models together, I perhaps had unwittingly got caught up in another design decision without realising. I actually started out with a forum model, which has since been broken into a forum, thread and post model. Your rules regarding grouping with read-only access to foreign territory, despite being evident, provides a rule by which to continue design without ambiguity.
I'm still split on which way to go. I have in mind future expansion, which has yet to take a form, but would imply an ORM style design would be beneficial. But should I be planning for this possibility now?
This is why I first posed the question - what do others do and think about this problem?
ps. Now I'll go and fix those quotations.
[eluser]jedd[/eluser]
I can't imagine splitting my current forum controller into thread, post, and forum components, and/or my message model into something similarly segregated. As in, I really can't imagine how I'd do such a thing .. partly because it'd be a big carve-up of what I've got now, but mostly because my brain just doesn't work that way (yet).
My message model - used by my forum and mail controllers - is about 1200 lines, or 560 lines of actual PHP. I feel that this is Quite Acceptable in the size & performance stakes. It's not complete yet, but might blow out by another 20-30%. Still within the Acceptable Size region, IMO.
ORM's - never seen the appeal, but I'm not an OO type. If I were, and it was a new project with a new database, I'd probably go for a native OO DB (say db4o) rather than trying to squeeze a conventional RDBMS like MySQL into an object-mapping glove.
My approach of only one model having write-rights to a given table has worked well for me to far, though I did have one occasion where it was a bit tricky to maintain that approach. I have fairly modest requirements and a fairly modestly scoped project, so this might not scale so well for you. It does, as you say, provide for a non-ambiguous policy across your entire codebase though, if you can sustain it.
Oh, and when you talk of models being agnostic - do you mean, presenting data to the controller in a schema-agnostic way, or in the sense that one model shouldn't know anything about the schema outside its own area of interest/ownership?
[eluser]kurucu[/eluser]
[quote author="jedd" date="1253822581"]I can't imagine splitting my current forum controller into thread, post, and forum components, and/or my message model into something similarly segregated. As in, I really can't imagine how I'd do such a thing .. partly because it'd be a big carve-up of what I've got now, but mostly because my brain just doesn't work that way (yet).[/quote]
Interestingly, not so long ago neither could I. I previously used my models such that they know about their capability (Aircraft terminology)... I think I mean area of the problem domain in official terminology. The point being that they know about the schema, it's relationships and inner workings, and presented "Discussion", "User Management", "Authentication" (inc permissions etc), "CMS" groupings of functions to the Controllers.
However, in joining this forum and skimming through the various posts, documentation and other references used, I started to feel that a more OO approach would be useful. Indeed, all it has done is split up (and perhaps clarify) a larger model. I have been lucky until now that a change of this size hasn't been a massive undertaking.
[quote author="jedd" date="1253822581"]My message model - used by my forum and mail controllers - is about 1200 lines, or 560 lines of actual PHP. I feel that this is Quite Acceptable in the size & performance stakes. It's not complete yet, but might blow out by another 20-30%. Still within the Acceptable Size region, IMO.[/quote]Each of my individual models are around 150 lines, so I guess about equivalent after you add them all up with private messaging and whatnot. Although your's sounds more efficient and, well, intriguing.
[quote author="jedd" date="1253822581"]ORM's - never seen the appeal, but I'm not an OO type. If I were, and it was a new project with a new database, I'd probably go for a native OO DB (say db4o) rather than trying to squeeze a conventional RDBMS like MySQL into an object-mapping glove.[/quote]I am constrained, wrongly so perhaps, by my hosting provider. Perhaps this (and version control) could be fixed by a hosting move. In the meantime, I'm stuck with the gauntlet and MySQL. Assuming I take that route. This is still the question.
[quote author="jedd" date="1253822581"]I have fairly modest requirements and a fairly modestly scoped project, so this might not scale so well for you. It does, as you say, provide for a non-ambiguous policy across your entire codebase though, if you can sustain it.[/quote]Mine's presently modest but with an eye on ambition. Either way, I'd rather have a rule I didn't like following than anarchy in my code. What's more, is that the overheads of ORM have yet to convince me compared to a structure like yours. You present it as personal, and that's its advantage: efficiency and applicability.
[quote author="jedd" date="1253822581"]Oh, and when you talk of models being agnostic - do you mean, presenting data to the controller in a schema-agnostic way, or in the sense that one model shouldn't know anything about the schema outside its own area of interest/ownership?[/quote]The former, for sure, but an element of de-coupling is useful for any changes down the line. For example, my tables have foreign keys, so my newly split models might provide a post table with the ability to: get all posts, get a single post, get a post count, get posts for X thread, get posts for X user, insert and update. Also, all functions returning more than one row have hooks for pagination.
This means to find out about the thread and posts within, I must use both models. Previously, I used a get_thread function which returned the thread header information and all its posts. I use my discussion models as an example, but it applies across the board.
|
