On 3/8/2011 11:10 AM, Le_Forgeron wrote:
>
> If the pieces of data are common or shared, even by the tiniest amount,
> a single database is the answer.
>
> Otherwise, how would you handle data's coherency ?
>
> Access won't scale, drop it past the template step.
> I won't enter holy wars about other SQL engines, but MySQL is rather
> light (well, it get better every year).
> You might really get benefit from engine which support views.
>


no, not asking for a holy war :-)  tho MySQL is my default if we go the 
single database engine direction.


views present an interesting option - possibly ways of flattening the 
database without requiring that the data itself be flattened

I also like the 'snapshot' of job data export that Andrew mentioned - 
might fix some of our concerns.


>>
>> 3.  Normalizing vs Flattening?  At what point is a database 'too'
>> normalized and does it matter?  Do you have some thoughts on joins using
>> text data types instead of integer numbers?
>
> Do not optimise before actual tests.
>
> Normalise at least to 3rd form for your data, and keep it so!
> The schema of the database should be checked up to 5th form, but that
> usually transparent with good database people that are used to the task.
>
> Conceiving the full schema (for all jobs) is needed before writing the
> first line, or you will end up rewriting code when a job breaks a
> relationship in many...
>
> If you have performance issue, adding some index can help.
> If you are normalised to 3++, you should not have blob of data to scan
> to achieve your tasks.
>

Yes, the data needs to be well understood before starting the schema. 
There should be no anomalies to 'fit in' after the fact.

But the fact is that we have limited time to put this together in and a 
lot of data that can be rather tightly intertwined.  So we have to run 
with 90% and figure out how to cleanly fit things in as we go along. 
Not the best approach, but it does make it 'usable' earlier.

We are at the point of stepping back and trying to put together a better 
schema.


FYI, my questions and information may seem a bit vague and informal as I 
am trying to keep my personal bias out of what you guys feed back.



> Last point: any personal data (such as name of customer) might requires
> the clearance of the local law authority (declaring the database, and
> getting it allowed, obligation to allow query and modify on basis of
> remote people)... For instance, the IP address is such personal piece,
> even without name.
>

Thanks for the tip - tho we don't track people or their data.  We look 
at telephone poles :-)


Thanks :-)

Post a reply to this message