Rainboy <mark.rainbow (AT) gmail (DOT) com> writes:

I think you may be a little off the mark with your interpretation of
3NF. Its not about not storing calculated values. Although a bit
simplistic, think of it as not having the same data stored in multiple
places because then you can get data inconsistencies when one copy is
updated and the other is not - how do you determine which is correct?

Also, don't worry too much about efficiency initially. What your
describing is normal expected application of the technology. You also
don't seem to be dealing with that many records given common data set
sizes and the processing power of hardware these days. Optimizing too
early is often a fatal mistake. Wait and see (ideally in a testing stage
rather than a production stage - you will be surprised how much
performance can be affected by the right use of indexes. If performance
becomes an issue and you cannot resolve it with available database
features (partitioning, indexing, summary tables, views etc) then you
can consider using summary tables and data archiving etc.

Think about it from a different perspective. The problem isn't that the
balances get all messed up. The problem is allowing historical data to
be modified. If you cannot change the balance or date of a record and
you cannot insert a record with a retrospective date, then your
historical data doesn't change and hence any calculations based on that
data doesn't change. Note that most accountants and auditors would not
be very impressed with any system that allowed either updates of past
records or insertion of records retrospectively.
Personally, I'd avoid storing the balance unless the calculation of that
balance is too resource hungry. As long as you can't change data
retrospectively and can't insert records retrospectively, just calculate
the balance when you need it.

What I would possibly do is -

1. Use a timestamp on the records that is automatically set when you
insert the record. i.e. not set by the user.

2. If performance becomes an issue, consider having either some form of
partitioning or end of month process. Track when the end of month
process has been run and use that to generate a historical summary
table. If/when you need a detailed report that covers more than the
current period, use the data in the historical summary table.

3. Take advantage of 300 years of modern accounting practices and design
your system as a double entry accounting system. This provides
additional checks and balances and you tend to get lots of other
benefits, such as simplified auditing processes. Include the ability to
enter bank statements or deposit receipts. This can be used to ensure
everything balances. Don't allow a month to be closed off until
everythinig balances.

4. Ensure you have some type of journaling function that will enable
adjustments. Data will be entered incorrectly - that is the one thing
you can guarantee - for example, simple transposing of numbers during
data entry etc. You need to be able to 'fix' such things and you need to
be able to do it in an acceptable way from and accounting and auditing
perspective. Rule of thumb, you should be able to reproduce *all* the
data entry processes that have occured easily and pretty much
transparently.

5. If your database supports constraints (foreign keys, check
constraints, not null, primary key constraints, etc then use them. In
the short term, it may feel like a lot of extra work, but once you start
coding the application logic, things become a lot easier. Much better to
prevent bad data from getting in than trying to fix it once it does.

6. Make sure you thoroughly know and understand how this information is
recorded and managed now. I'm assuming it is a manual system. Being
really familiar with current practice will provide valuable information
in both the design of your underlying data model and the overall
implementation. Don't try to just replicate the process using technology
- your solution wil almost certainly require those who manage the
process to refine their process, but make sure you understand their
current process before trying to design them a new one.

Finally, make sure there isn't an affordable or open source solution
that would suffice. Building such an application is a fun project and if
its for an organisation you feel warrants such support, its generally a
good thing. However, all applications need maintenance and support. If
your not prepared or unable to provide this maintenance and support,
they need to get it from somewhere else and it can come at a cost -
particularly for one off custom apps. Given you have never designed and
implemented a database and application before, you are almost certainly
going to get things wrong. I've been working in the industry for over 20
years and I still get things wrong - the only difference is that I get
it wrong less often and when I do it tends to be less critical.

good luck

Tim

--
tcross (at) rapttech dot com dot au

Rainboy <mark.rainbow (AT) gmail (DOT) com> writes:

I think you may be a little off the mark with your interpretation of
3NF. Its not about not storing calculated values. Although a bit
simplistic, think of it as not having the same data stored in multiple
places because then you can get data inconsistencies when one copy is
updated and the other is not - how do you determine which is correct?

Also, don't worry too much about efficiency initially. What your
describing is normal expected application of the technology. You also
don't seem to be dealing with that many records given common data set
sizes and the processing power of hardware these days. Optimizing too
early is often a fatal mistake. Wait and see (ideally in a testing stage
rather than a production stage - you will be surprised how much
performance can be affected by the right use of indexes. If performance
becomes an issue and you cannot resolve it with available database
features (partitioning, indexing, summary tables, views etc) then you
can consider using summary tables and data archiving etc.

Think about it from a different perspective. The problem isn't that the
balances get all messed up. The problem is allowing historical data to
be modified. If you cannot change the balance or date of a record and
you cannot insert a record with a retrospective date, then your
historical data doesn't change and hence any calculations based on that
data doesn't change. Note that most accountants and auditors would not
be very impressed with any system that allowed either updates of past
records or insertion of records retrospectively.
Personally, I'd avoid storing the balance unless the calculation of that
balance is too resource hungry. As long as you can't change data
retrospectively and can't insert records retrospectively, just calculate
the balance when you need it.

What I would possibly do is -

1. Use a timestamp on the records that is automatically set when you
insert the record. i.e. not set by the user.

2. If performance becomes an issue, consider having either some form of
partitioning or end of month process. Track when the end of month
process has been run and use that to generate a historical summary
table. If/when you need a detailed report that covers more than the
current period, use the data in the historical summary table.

3. Take advantage of 300 years of modern accounting practices and design
your system as a double entry accounting system. This provides
additional checks and balances and you tend to get lots of other
benefits, such as simplified auditing processes. Include the ability to
enter bank statements or deposit receipts. This can be used to ensure
everything balances. Don't allow a month to be closed off until
everythinig balances.

4. Ensure you have some type of journaling function that will enable
adjustments. Data will be entered incorrectly - that is the one thing
you can guarantee - for example, simple transposing of numbers during
data entry etc. You need to be able to 'fix' such things and you need to
be able to do it in an acceptable way from and accounting and auditing
perspective. Rule of thumb, you should be able to reproduce *all* the
data entry processes that have occured easily and pretty much
transparently.

5. If your database supports constraints (foreign keys, check
constraints, not null, primary key constraints, etc then use them. In
the short term, it may feel like a lot of extra work, but once you start
coding the application logic, things become a lot easier. Much better to
prevent bad data from getting in than trying to fix it once it does.

6. Make sure you thoroughly know and understand how this information is
recorded and managed now. I'm assuming it is a manual system. Being
really familiar with current practice will provide valuable information
in both the design of your underlying data model and the overall
implementation. Don't try to just replicate the process using technology
- your solution wil almost certainly require those who manage the
process to refine their process, but make sure you understand their
current process before trying to design them a new one.

Finally, make sure there isn't an affordable or open source solution
that would suffice. Building such an application is a fun project and if
its for an organisation you feel warrants such support, its generally a
good thing. However, all applications need maintenance and support. If
your not prepared or unable to provide this maintenance and support,
they need to get it from somewhere else and it can come at a cost -
particularly for one off custom apps. Given you have never designed and
implemented a database and application before, you are almost certainly
going to get things wrong. I've been working in the industry for over 20
years and I still get things wrong - the only difference is that I get
it wrong less often and when I do it tends to be less critical.

good luck

Tim

--
tcross (at) rapttech dot com dot au

Rainboy <mark.rainbow (AT) gmail (DOT) com> writes:

I think you may be a little off the mark with your interpretation of
3NF. Its not about not storing calculated values. Although a bit
simplistic, think of it as not having the same data stored in multiple
places because then you can get data inconsistencies when one copy is
updated and the other is not - how do you determine which is correct?

Also, don't worry too much about efficiency initially. What your
describing is normal expected application of the technology. You also
don't seem to be dealing with that many records given common data set
sizes and the processing power of hardware these days. Optimizing too
early is often a fatal mistake. Wait and see (ideally in a testing stage
rather than a production stage - you will be surprised how much
performance can be affected by the right use of indexes. If performance
becomes an issue and you cannot resolve it with available database
features (partitioning, indexing, summary tables, views etc) then you
can consider using summary tables and data archiving etc.

Think about it from a different perspective. The problem isn't that the
balances get all messed up. The problem is allowing historical data to
be modified. If you cannot change the balance or date of a record and
you cannot insert a record with a retrospective date, then your
historical data doesn't change and hence any calculations based on that
data doesn't change. Note that most accountants and auditors would not
be very impressed with any system that allowed either updates of past
records or insertion of records retrospectively.
Personally, I'd avoid storing the balance unless the calculation of that
balance is too resource hungry. As long as you can't change data
retrospectively and can't insert records retrospectively, just calculate
the balance when you need it.

What I would possibly do is -

1. Use a timestamp on the records that is automatically set when you
insert the record. i.e. not set by the user.

2. If performance becomes an issue, consider having either some form of
partitioning or end of month process. Track when the end of month
process has been run and use that to generate a historical summary
table. If/when you need a detailed report that covers more than the
current period, use the data in the historical summary table.

3. Take advantage of 300 years of modern accounting practices and design
your system as a double entry accounting system. This provides
additional checks and balances and you tend to get lots of other
benefits, such as simplified auditing processes. Include the ability to
enter bank statements or deposit receipts. This can be used to ensure
everything balances. Don't allow a month to be closed off until
everythinig balances.

4. Ensure you have some type of journaling function that will enable
adjustments. Data will be entered incorrectly - that is the one thing
you can guarantee - for example, simple transposing of numbers during
data entry etc. You need to be able to 'fix' such things and you need to
be able to do it in an acceptable way from and accounting and auditing
perspective. Rule of thumb, you should be able to reproduce *all* the
data entry processes that have occured easily and pretty much
transparently.

5. If your database supports constraints (foreign keys, check
constraints, not null, primary key constraints, etc then use them. In
the short term, it may feel like a lot of extra work, but once you start
coding the application logic, things become a lot easier. Much better to
prevent bad data from getting in than trying to fix it once it does.

6. Make sure you thoroughly know and understand how this information is
recorded and managed now. I'm assuming it is a manual system. Being
really familiar with current practice will provide valuable information
in both the design of your underlying data model and the overall
implementation. Don't try to just replicate the process using technology
- your solution wil almost certainly require those who manage the
process to refine their process, but make sure you understand their
current process before trying to design them a new one.

Finally, make sure there isn't an affordable or open source solution
that would suffice. Building such an application is a fun project and if
its for an organisation you feel warrants such support, its generally a
good thing. However, all applications need maintenance and support. If
your not prepared or unable to provide this maintenance and support,
they need to get it from somewhere else and it can come at a cost -
particularly for one off custom apps. Given you have never designed and
implemented a database and application before, you are almost certainly
going to get things wrong. I've been working in the industry for over 20
years and I still get things wrong - the only difference is that I get
it wrong less often and when I do it tends to be less critical.

good luck

Tim

--
tcross (at) rapttech dot com dot au

Rainboy <mark.rainbow (AT) gmail (DOT) com> writes:

I think you may be a little off the mark with your interpretation of
3NF. Its not about not storing calculated values. Although a bit
simplistic, think of it as not having the same data stored in multiple
places because then you can get data inconsistencies when one copy is
updated and the other is not - how do you determine which is correct?

Also, don't worry too much about efficiency initially. What your
describing is normal expected application of the technology. You also
don't seem to be dealing with that many records given common data set
sizes and the processing power of hardware these days. Optimizing too
early is often a fatal mistake. Wait and see (ideally in a testing stage
rather than a production stage - you will be surprised how much
performance can be affected by the right use of indexes. If performance
becomes an issue and you cannot resolve it with available database
features (partitioning, indexing, summary tables, views etc) then you
can consider using summary tables and data archiving etc.

Think about it from a different perspective. The problem isn't that the
balances get all messed up. The problem is allowing historical data to
be modified. If you cannot change the balance or date of a record and
you cannot insert a record with a retrospective date, then your
historical data doesn't change and hence any calculations based on that
data doesn't change. Note that most accountants and auditors would not
be very impressed with any system that allowed either updates of past
records or insertion of records retrospectively.
Personally, I'd avoid storing the balance unless the calculation of that
balance is too resource hungry. As long as you can't change data
retrospectively and can't insert records retrospectively, just calculate
the balance when you need it.

What I would possibly do is -

1. Use a timestamp on the records that is automatically set when you
insert the record. i.e. not set by the user.

2. If performance becomes an issue, consider having either some form of
partitioning or end of month process. Track when the end of month
process has been run and use that to generate a historical summary
table. If/when you need a detailed report that covers more than the
current period, use the data in the historical summary table.

3. Take advantage of 300 years of modern accounting practices and design
your system as a double entry accounting system. This provides
additional checks and balances and you tend to get lots of other
benefits, such as simplified auditing processes. Include the ability to
enter bank statements or deposit receipts. This can be used to ensure
everything balances. Don't allow a month to be closed off until
everythinig balances.

4. Ensure you have some type of journaling function that will enable
adjustments. Data will be entered incorrectly - that is the one thing
you can guarantee - for example, simple transposing of numbers during
data entry etc. You need to be able to 'fix' such things and you need to
be able to do it in an acceptable way from and accounting and auditing
perspective. Rule of thumb, you should be able to reproduce *all* the
data entry processes that have occured easily and pretty much
transparently.

5. If your database supports constraints (foreign keys, check
constraints, not null, primary key constraints, etc then use them. In
the short term, it may feel like a lot of extra work, but once you start
coding the application logic, things become a lot easier. Much better to
prevent bad data from getting in than trying to fix it once it does.

6. Make sure you thoroughly know and understand how this information is
recorded and managed now. I'm assuming it is a manual system. Being
really familiar with current practice will provide valuable information
in both the design of your underlying data model and the overall
implementation. Don't try to just replicate the process using technology
- your solution wil almost certainly require those who manage the
process to refine their process, but make sure you understand their
current process before trying to design them a new one.

Finally, make sure there isn't an affordable or open source solution
that would suffice. Building such an application is a fun project and if
its for an organisation you feel warrants such support, its generally a
good thing. However, all applications need maintenance and support. If
your not prepared or unable to provide this maintenance and support,
they need to get it from somewhere else and it can come at a cost -
particularly for one off custom apps. Given you have never designed and
implemented a database and application before, you are almost certainly
going to get things wrong. I've been working in the industry for over 20
years and I still get things wrong - the only difference is that I get
it wrong less often and when I do it tends to be less critical.

good luck

Tim

--
tcross (at) rapttech dot com dot au

Rainboy <mark.rainbow (AT) gmail (DOT) com> writes:

I think you may be a little off the mark with your interpretation of
3NF. Its not about not storing calculated values. Although a bit
simplistic, think of it as not having the same data stored in multiple
places because then you can get data inconsistencies when one copy is
updated and the other is not - how do you determine which is correct?

Also, don't worry too much about efficiency initially. What your
describing is normal expected application of the technology. You also
don't seem to be dealing with that many records given common data set
sizes and the processing power of hardware these days. Optimizing too
early is often a fatal mistake. Wait and see (ideally in a testing stage
rather than a production stage - you will be surprised how much
performance can be affected by the right use of indexes. If performance
becomes an issue and you cannot resolve it with available database
features (partitioning, indexing, summary tables, views etc) then you
can consider using summary tables and data archiving etc.

Think about it from a different perspective. The problem isn't that the
balances get all messed up. The problem is allowing historical data to
be modified. If you cannot change the balance or date of a record and
you cannot insert a record with a retrospective date, then your
historical data doesn't change and hence any calculations based on that
data doesn't change. Note that most accountants and auditors would not
be very impressed with any system that allowed either updates of past
records or insertion of records retrospectively.
Personally, I'd avoid storing the balance unless the calculation of that
balance is too resource hungry. As long as you can't change data
retrospectively and can't insert records retrospectively, just calculate
the balance when you need it.

What I would possibly do is -

1. Use a timestamp on the records that is automatically set when you
insert the record. i.e. not set by the user.

2. If performance becomes an issue, consider having either some form of
partitioning or end of month process. Track when the end of month
process has been run and use that to generate a historical summary
table. If/when you need a detailed report that covers more than the
current period, use the data in the historical summary table.

3. Take advantage of 300 years of modern accounting practices and design
your system as a double entry accounting system. This provides
additional checks and balances and you tend to get lots of other
benefits, such as simplified auditing processes. Include the ability to
enter bank statements or deposit receipts. This can be used to ensure
everything balances. Don't allow a month to be closed off until
everythinig balances.

4. Ensure you have some type of journaling function that will enable
adjustments. Data will be entered incorrectly - that is the one thing
you can guarantee - for example, simple transposing of numbers during
data entry etc. You need to be able to 'fix' such things and you need to
be able to do it in an acceptable way from and accounting and auditing
perspective. Rule of thumb, you should be able to reproduce *all* the
data entry processes that have occured easily and pretty much
transparently.

5. If your database supports constraints (foreign keys, check
constraints, not null, primary key constraints, etc then use them. In
the short term, it may feel like a lot of extra work, but once you start
coding the application logic, things become a lot easier. Much better to
prevent bad data from getting in than trying to fix it once it does.

6. Make sure you thoroughly know and understand how this information is
recorded and managed now. I'm assuming it is a manual system. Being
really familiar with current practice will provide valuable information
in both the design of your underlying data model and the overall
implementation. Don't try to just replicate the process using technology
- your solution wil almost certainly require those who manage the
process to refine their process, but make sure you understand their
current process before trying to design them a new one.

Finally, make sure there isn't an affordable or open source solution
that would suffice. Building such an application is a fun project and if
its for an organisation you feel warrants such support, its generally a
good thing. However, all applications need maintenance and support. If
your not prepared or unable to provide this maintenance and support,
they need to get it from somewhere else and it can come at a cost -
particularly for one off custom apps. Given you have never designed and
implemented a database and application before, you are almost certainly
going to get things wrong. I've been working in the industry for over 20
years and I still get things wrong - the only difference is that I get
it wrong less often and when I do it tends to be less critical.

good luck

Tim

--
tcross (at) rapttech dot com dot au

Rainboy <mark.rainbow (AT) gmail (DOT) com> writes:

I think you may be a little off the mark with your interpretation of
3NF. Its not about not storing calculated values. Although a bit
simplistic, think of it as not having the same data stored in multiple
places because then you can get data inconsistencies when one copy is
updated and the other is not - how do you determine which is correct?

Also, don't worry too much about efficiency initially. What your
describing is normal expected application of the technology. You also
don't seem to be dealing with that many records given common data set
sizes and the processing power of hardware these days. Optimizing too
early is often a fatal mistake. Wait and see (ideally in a testing stage
rather than a production stage - you will be surprised how much
performance can be affected by the right use of indexes. If performance
becomes an issue and you cannot resolve it with available database
features (partitioning, indexing, summary tables, views etc) then you
can consider using summary tables and data archiving etc.

Think about it from a different perspective. The problem isn't that the
balances get all messed up. The problem is allowing historical data to
be modified. If you cannot change the balance or date of a record and
you cannot insert a record with a retrospective date, then your
historical data doesn't change and hence any calculations based on that
data doesn't change. Note that most accountants and auditors would not
be very impressed with any system that allowed either updates of past
records or insertion of records retrospectively.
Personally, I'd avoid storing the balance unless the calculation of that
balance is too resource hungry. As long as you can't change data
retrospectively and can't insert records retrospectively, just calculate
the balance when you need it.

What I would possibly do is -

1. Use a timestamp on the records that is automatically set when you
insert the record. i.e. not set by the user.

2. If performance becomes an issue, consider having either some form of
partitioning or end of month process. Track when the end of month
process has been run and use that to generate a historical summary
table. If/when you need a detailed report that covers more than the
current period, use the data in the historical summary table.

3. Take advantage of 300 years of modern accounting practices and design
your system as a double entry accounting system. This provides
additional checks and balances and you tend to get lots of other
benefits, such as simplified auditing processes. Include the ability to
enter bank statements or deposit receipts. This can be used to ensure
everything balances. Don't allow a month to be closed off until
everythinig balances.

4. Ensure you have some type of journaling function that will enable
adjustments. Data will be entered incorrectly - that is the one thing
you can guarantee - for example, simple transposing of numbers during
data entry etc. You need to be able to 'fix' such things and you need to
be able to do it in an acceptable way from and accounting and auditing
perspective. Rule of thumb, you should be able to reproduce *all* the
data entry processes that have occured easily and pretty much
transparently.

5. If your database supports constraints (foreign keys, check
constraints, not null, primary key constraints, etc then use them. In
the short term, it may feel like a lot of extra work, but once you start
coding the application logic, things become a lot easier. Much better to
prevent bad data from getting in than trying to fix it once it does.

6. Make sure you thoroughly know and understand how this information is
recorded and managed now. I'm assuming it is a manual system. Being
really familiar with current practice will provide valuable information
in both the design of your underlying data model and the overall
implementation. Don't try to just replicate the process using technology
- your solution wil almost certainly require those who manage the
process to refine their process, but make sure you understand their
current process before trying to design them a new one.

Finally, make sure there isn't an affordable or open source solution
that would suffice. Building such an application is a fun project and if
its for an organisation you feel warrants such support, its generally a
good thing. However, all applications need maintenance and support. If
your not prepared or unable to provide this maintenance and support,
they need to get it from somewhere else and it can come at a cost -
particularly for one off custom apps. Given you have never designed and
implemented a database and application before, you are almost certainly
going to get things wrong. I've been working in the industry for over 20
years and I still get things wrong - the only difference is that I get
it wrong less often and when I do it tends to be less critical.

good luck

Tim

--
tcross (at) rapttech dot com dot au

On Jul 16, 3:00 pm, Rainboy <mark.rain... (AT) gmail (DOT) com> wrote:
3NF is deprecated really. You should start at BCNF when normalizing.
Regards, J.

On Jul 16, 3:00 pm, Rainboy <mark.rain... (AT) gmail (DOT) com> wrote:
3NF is deprecated really. You should start at BCNF when normalizing.
Regards, J.

On Jul 16, 3:00 pm, Rainboy <mark.rain... (AT) gmail (DOT) com> wrote:
3NF is deprecated really. You should start at BCNF when normalizing.
Regards, J.

On Jul 16, 3:00 pm, Rainboy <mark.rain... (AT) gmail (DOT) com> wrote:
3NF is deprecated really. You should start at BCNF when normalizing.
Regards, J.