| Echoing results from a database |
[eluser]jedd[/eluser]
Quote:id - siteTitle - adminEmail if you're using MySQL - describe table (output) or the CREATE table (input) are good ways to show schema design - people are used to interpreting those layouts. For future reference, I mean.  From [url="http://ellislab.com/codeigniter/user-guide/general/models.html"]http://ellislab.com/codeigniter/user-guide/general/models.html[/url] the observation that: Class names must have the first letter capitalized with the rest of the name lowercase. Not sure what happens if you don't, but is the risk worth it? <bites nails> Probably not.
[eluser]mdcode[/eluser]
Hmmm... I don't think I will even try to fake that I understood what you said there I'm afraid - I'm quite new to php coding from scratch on my own (could you tell?). Although the data would not change on a day to day basis, it just made more sense to hold the information in the database to have the site more dynamically generated. Plus this is the first page of the site so it was necessary to get this far at least to make sure things were working so I could move on... If you would be willing to virtually hand-hold me on you last post, I'd be more than happy to listen to a better and more efficient way of doing things.
[eluser]mdcode[/eluser]
[quote author="jedd" date="1236831755"] Quote:if you're using MySQL - describe table (output) or the CREATE table (input) are good ways to show schema design - people are used to interpreting those layouts. For future reference, I mean.[/quote] Thanks for the info jedd, I'm sort of new to this and is seemed an ok way to post information on the schema, I'll remember for next time though. As for the capitalisation, yep, I caught that while reading through the documentation again trying to help myself while waiting for help from here, and changed those this morning just after my post containing that quote, but thanks for the reminder. This is like learning to ride a bike again when you have to install the pedals first...
[eluser]jedd[/eluser]
If I may .. Fuzzy's point is that storage of data that doesn't change much, and doesn't need to be indexed (not hard to find what you want in the set of data), and is quite small - make the data good candidates for not being stored in a database. Consider a bunch of your data - you have a number of ways of storing it. If it was an array full of different types of data - strings, characters, numbers, other arrays, etc - then you could pull it apart and store each bit in the right place (lots of different tables) in a database. Or you 'serialize' it - which means to convert a 'lump of data' into an easily storable form that you can later, as you'd expect, unserialize back into the original lump of data. This is much faster / easier than breaking it apart and dumping into a database, and then carefully reassembling it from that database later. But .. in this case.. your motivation (get DB connectivity going, etc) makes sense, as does the goal of portability.
[eluser]jedd[/eluser]
Oh .. don't worry about the bike-learning aspect. I'm probably a few weeks ahead of you. If that. With models - the goal (I believe) is to try to make them reflect your data as closely as possible. In a true Active Record approach you'd have a model for each table in your database, for instance. This isn't hard and fast with non-(strict)-AR stuff, of course. Models should reflect how your data presents, as much as how it is stored (IMHO). There are plenty of good discussions about this out on the Intergoogle. I mention this in part because I started to make 'Xyz_model' classnames in my models, and got annoyed at that real quick, and so then tried to approach the design from both ends at the same time. That is - my models reflect the data (I have one model that owns about 25 tables, for example). My controllers reflect how users will see the system. There may be times that these correlate, but by looking at it this way I got a clearer idea of how to design both halves, plus I didn't get the conflicts on class names in models & controllers. Which made me happy. If you're new to this stuff, I highly recommend that you keep a couple of web pages open all the time - ideally pointing to local copies of these things: o MySQL documentation o PHP5 documentation o Code Igniter User's Guide For instance, the PHP5 function-index is a good way of finding the serialize function, which then describes much more succinctly than I did, exactly what it does.
[eluser]mdcode[/eluser]
I appreciate any and all input... Now, if I'm understanding you, and Fuzzy, correctly then I think that I am using the database correctly, since the things stored in these particular tables are rarely changing. The intro text, while only used on the front page for instance, is a 'large' block of text pulled from a TEXT type field in the database. While the other items are quite small, such as the adminEmail and siteTitle, and could be held in a special config file, it seems superfluous to then hold the intro text in the database since it would then be the only item in there. Thinking aloud, I guess then though, I could just make that static text on the home page just like the "Welcome to the" is right now, and drop two tables out of the db.
[eluser]TheFuzzy0ne[/eluser]
[quote author="jedd" date="1236831755"]Not sure what happens if you don't, but is the risk worth it? <bites nails> Probably not.[/quote] I don't fully understand the reasons either, but I've been led to believe that some Linux systems are anal about case.
[eluser]jedd[/eluser]
A lot of this is six of one stuff. There is no clear 'right' way of doing a lot of things, which can be a tad frustrating. If the intro text ever needs to be updated by someone - and that someone will be a user (rather than you) then you'll need a way of making that change. That's the only real consideration there. Same consideration for site title, admin email, contact-us, etc. Database lookups can be expensive, but they're not as expensive as you may think. It's instructive to play with the [url="http://ellislab.com/codeigniter/user-guide/general/profiling.html"]profiling feature of CI[/url] to get an insight into just how expensive different things are, particularly your database calls. Mind, you'll find that [url="http://ellislab.com/codeigniter/user-guide/general/caching.html"]caching[/url] might negate your concerns in this example anyway.
[eluser]jedd[/eluser]
Quote:I don't fully understand the reasons either, but I've been led to believe that some Linux systems are anal about case. Hey! GNU/Linux systems are anal about everything. That's part of the appeal. In this case though - the ucfirst() requirement applies within the file contents, so nothing to do with the OS or the FS. This is definitely a CI requirement, though it doesn't seem to be enforced. Or rather, nothing seems to break if you ignore it.
[eluser]TheFuzzy0ne[/eluser]
[quote author="mdcode" date="1236833345"]I appreciate any and all input... Now, if I'm understanding you, and Fuzzy, correctly then I think that I am using the database correctly, since the things stored in these particular tables are rarely changing. The intro text, while only used on the front page for instance, is a 'large' block of text pulled from a TEXT type field in the database. While the other items are quite small, such as the adminEmail and siteTitle, and could be held in a special config file, it seems superfluous to then hold the intro text in the database since it would then be the only item in there. Thinking aloud, I guess then though, I could just make that static text on the home page just like the "Welcome to the" is right now, and drop two tables out of the db.[/quote] My suggestion would be something like this: In ./system/application/config/config.php: Code: $config['admin_email'] = '[email protected]';The config file is automatically loaded by CodeIgniter, so you can grab the values using $this->config->item('site_title') and so on. You're free to change the data as you see fit, and it's probably easier than editing a database, as you just need to open a file and edit it. Basically, the information will be there for you readily on each request - no need to mess about with databases. Consider a database table to be a bit like a big-ass CD rack. You wouldn't buy a CD rack capable of holding 200 CDs to hold only one CD, would you? ...Or would you?? The other reason for my suggestion is that you seem to be querying the database once for each setting, which is not very efficient. |
| Welcome Guest, Not a member yet? Register Sign In |
