db Structure

I don't understand, you wish to join project, and rewrite the core ?

No, I'm researching possible options to give a client what they need in the most expeditious and efficient manner as possible.

The project will easily exceed 100,000 items. The project involves updating a music industry catalog and related information.

So while the structure of your component may be normalized, my question had to do with the users data. With every entry that is made on the site, we need to minimize the redundancy(normalization). For example for album data, if users would have to enter the artists name and info with each album submitted, the db is not normalized, because the same information is listed several times. In addition if different types of user data is stored in basically one table, its not normalized. Without mentioning any names, they are quite a few components that function this way.

Thanks for your intelligent response George.

For the peanut gallery... ha-ha very funny. Hmmm lets see, spend 2-4 hours installing a component, figuring out how it works to determine if it does what you need it to do, or spend 10 min. asking the developer? :roll:

From your features page:

Please note that FLEXIcontent allows you to associate a same field to multiple types.

This may work. When I submitted my original post, the Features page would not load for some reason, may have been my connection, thus the question to begin with. Although just now, I went to load it, and had to refresh the page to get it to display.

I look forward to learning more and using Flexi.

dezblanco wrote: For the peanut gallery... ha-ha very funny. Hmmm lets see, spend 2-4 hours installing a component, figuring out how it works to determine if it does what you need it to do, or spend 10 min. asking the developer? :roll:

Well, a project with more than 100.000 items sounds like a whole field of peanut trees...

By the way, I do not know if you have experience with Joomla and if yes what components you are using, but installing FlexiContent in an existing Joomla installation takes less than 10 minutes. Anyway, I am out of this thread.

Rooney

a subjestion
use flexi import to convert your database for flexicontent database ...

FLEXIcontent is a generic component for content management which sits on top of joomla, this is a bonus of not canceling joomla and ...

Joomla itself is partly normalized but you are using it.

About, the way the data are entered in the forms, it does not mean, that they are entered the same way in the database. And we cannot easily change database, a lot of code updating will be required , plus compatibility and upgrade / downgrade issues etc ...

Anyway the redundancy in FLEXIcontent db is rather small, THERE ARE TABLES FOR RELATIONS and is not worth tampering with to make the source code more complex !!!

Now about performance this is a big topic too, the database size or queries might not be the only problem, e.g. joomla plugin system will call all "listeners" registered to an event even if you want to call specific plugins only (the FLEXIcontent choosing of content plugins to call for a FLEXIcontent field, unfortunately calls all content plugins loaded up to the pointing of calling, so it calls more content plugins that those you choose).

For FLEXIcontent fields (aka plugins) the new FC versions bypass joomla plugin system to call plugin functions directly, the gains of this is small, since inside the plugin function of FLEXIcontent field (plugins), we have a check that returns immediately,

but for content plugins this is not the case, since they are made to execute always on a particular event, and if we can bypass joomla calling of content plugins, to call specific, plugins the performance gain in category view will be big.

I have done this 95%, but i need to finish and include it next version.

About being more flexible/convenient i don't know since FLEXIcontent has
-- smart heritage of parameters e.g. for item:
a. Global params
b. Category params (new !!!)
b. Type Params
c. Item Params
-- Easy to track templating in items / category manager tabs (and will add more too)
-- Massive copy for category parameters
-- (will have) Massive copy of items parameters

The above are very useful when managing a big site.

Anyway if i had or make an installation of 100,000 items i could profile it and find bottlenecks to optimize (i mean more towards code and queries and less towards the database schema) anyway as you say there are other components that maybe more suitable if you have this site.

Best Regards