Welcome Guest, Not a member yet? Register   Sign In
Newbie confusion about the database docs
#21

[eluser]Doug Lerner[/eluser]
Well, what are people's general strategies in storing object data?

If you have an object and the object's properties are simple, like strings or numbers, then it is pretty obvious that an object can correspond to a table and each record is an object's instance.

But what about more complicated objects?

Like say you have a user record and you want to add a property to it and that property is an associative array and some of the array elements themselves are objects or other associative arrays? In my current development I run into situations all the time where I end up with complex objects within objects within arrays within objects which need to be stored.

In my current development, which uses a minor, proprietary server-side JavaScript and included proprietary object-oriented database, I just store the object and that's that. But I want to move into something more open-source with a larger community of developers, like PHP, which is why I've been looking at CodeIgniter. I want to move into MVC, but I also want to be able to freely handle any kind of object while developing.

Do people spend a lot of time elaborately laying out complicated table structures manually linking one table to another, etc., just to design each object? That would take a lot of development time.

Or at some point do you just shrug and serialize/unserialize for storage and retrieval of complicated objects?

What is considered best practices for this sort of thing in CI?

Thanks,

doug
#22

[eluser]Colin Williams[/eluser]
Quote:What is considered best practices for this sort of thing in CI?

There is no best practice particular to CI for storing data objects. Database design and data normalization are skills a developer should pick up along the way.

Quote:Do people spend a lot of time elaborately laying out complicated table structures manually linking one table to another, etc., just to design each object? That would take a lot of development time.

Not a lot of time, no. Let's say you have two data objects which share a many-to-many relationship. At most you're designing and creating 3 tables. Something like post, category, and post_category to link them. Then in your model, you're just doing a JOIN query and then probably looping through the result and concatenating it into just an array of 'post' objects each with a 'category' property that is itself an array of 'category' objects. I don't think it's a lot of development overhead.

I like to have total control over my objects and their relationships so I typically avoid ORM-type frameworks. There are times ORM introduces more overhead than is necessary. If you would like to use something like ORM, head over to the wiki and have a peak at the few ORM-type libraries available.
#23

[eluser]Doug Lerner[/eluser]
[quote author="Colin Williams" date="1215667813"]Not a lot of time, no. Let's say you have two data objects which share a many-to-many relationship. At most you're designing and creating 3 tables. Something like post, category, and post_category to link them. Then in your model, you're just doing a JOIN query and then probably looping through the result and concatenating it into just an array of 'post' objects each with a 'category' property that is itself an array of 'category' objects. I don't think it's a lot of development overhead.

I like to have total control over my objects and their relationships so I typically avoid ORM-type frameworks. There are times ORM introduces more overhead than is necessary. If you would like to use something like ORM, head over to the wiki and have a peak at the few ORM-type libraries available.[/quote]

Well, it's a lot more development overhead than just creating the objects you want and storing them directly in an object-oriented database and letting the language take care of that for you.

I guess I have gotten so used to the particular server-side JavaScript I've been using I am resistant to spending time on the lower-level of the database handling, which has always been automatic to me. I'd much rather spend time on the higher-level coding logic than in dealing with all the details of how the data actually is handled in the tables.

Maybe I will go peak at the ORM stuff. Thanks for pointing that out.

doug
#24

[eluser]Chris Newton[/eluser]
As far as I'm concerned dealing with getting data in and out of the database safely is the biggest headache there is. It takes a lot of time to set up a database & join tables, and then do all the stuff Collin mentioned without getting any errors.

ORM *can* simplify the process, though it requires structuring your database tables in a certain manner (usually) and overriding this structure where necessary.
#25

[eluser]Doug Lerner[/eluser]
[quote author="mahuti" date="1215674337"]As far as I'm concerned dealing with getting data in and out of the database safely is the biggest headache there is. It takes a lot of time to set up a database & join tables, and then do all the stuff Collin mentioned without getting any errors.

ORM *can* simplify the process, though it requires structuring your database tables in a certain manner (usually) and overriding this structure where necessary.[/quote]

Yes, I can see that in the existing framework that getting data in and out of the database safely is the biggest headache there is and that it takes a lot of time to set up, etc. That is why I'm trying to avoid that headache. Smile

I'm just used to not even having to think about how the data actually gets in and out of the database. So I was hoping there was a common way of dealing with this.

Thanks,

doug

p.s. Sorry this conversation is now going on in two separate topic threads. I didn't mean for that to happen. It's just that the discussions seemed to have merged....




Theme © iAndrew 2016 - Forum software by © MyBB