S
Saccess
Hello Newsgroup,
I have (previously) constructed a backend (application file) using Access 2003, I
am now upgrading (due to substantial application upgrades) the backend
(application file) to Access 2007. Generally, the application file stores imported
matrices of integers, and doubles which the user is able to perform calculations
on, and graph. The imported matrices were never more than 248 column in size, so
placing a matrix of numbers in one table was never an issue. Briefly, the data the
application deals with is market research data.
The numeric matrices can now be arbitrary in length, that is I have one matrix
that has 1,376 columns, of type long (integer in the programming language).
Despite the row count, I am able to store the matrices in Memo fields as coma, new
line delimiter strings. This works just fine, even performance wise. Extracting a
matrix from a, record x field, I break up the delimiters, cast from String to
either Int32, or Double accordingly, and perform requested calculations, and
graphing. Nothing broken, performance is good, but, something has me thinking...
Rather than store the data matrices in memo fields (hence requiring some kind of
delimiter), why not look into storing the data matrices into OLE Object fields.
This may relieve the need for delimiters. Despite being confident I can achieve
this, what I do not know is, in this situation would there be any advantages in
doing so? What would the disadvantages be? Is it worth doing?, and Is actually
this possible? Best stick with Memo fields?
I don't really want to implement a matrix spanning over many tables of one-to-one
join, unless you claim this is the best way.
e.g;
Table: ResponseMatrix
===========================================
ID | MatrixName | DataType | Data (Currently Memo)
===========================================
1 | Brand | 0 | 1, 43,1,23,45,56,66,.....21
| | | 2, 5,23,456,65,45,.....3
| | | n, .......................
----------------------------------------------------------------
34 | Segments | 0 | another matrix like the above....
----------------------------------------------------------------
56 | Motivation | 1 | another matrix like the above....
----------------------------------------------------------------
77 | .... | ... | another matrix like the
above....
===========================================
C#: OleDb data access layer
C#: Application rules layer
C#: Interface
Would like;
===========================================
ID | MatrixName | DataType | Data (OLEObject)
===========================================
1 | Brand | 0 | 1 43 1 23 45 56 66 ..... 21
| | | 2 5 23 456 65 45 .....3
| | | n .......................
----------------------------------------------------------------
I know I would not see the data in this type of field until extracted.
Thanks and regards,
- Saccess
I have (previously) constructed a backend (application file) using Access 2003, I
am now upgrading (due to substantial application upgrades) the backend
(application file) to Access 2007. Generally, the application file stores imported
matrices of integers, and doubles which the user is able to perform calculations
on, and graph. The imported matrices were never more than 248 column in size, so
placing a matrix of numbers in one table was never an issue. Briefly, the data the
application deals with is market research data.
The numeric matrices can now be arbitrary in length, that is I have one matrix
that has 1,376 columns, of type long (integer in the programming language).
Despite the row count, I am able to store the matrices in Memo fields as coma, new
line delimiter strings. This works just fine, even performance wise. Extracting a
matrix from a, record x field, I break up the delimiters, cast from String to
either Int32, or Double accordingly, and perform requested calculations, and
graphing. Nothing broken, performance is good, but, something has me thinking...
Rather than store the data matrices in memo fields (hence requiring some kind of
delimiter), why not look into storing the data matrices into OLE Object fields.
This may relieve the need for delimiters. Despite being confident I can achieve
this, what I do not know is, in this situation would there be any advantages in
doing so? What would the disadvantages be? Is it worth doing?, and Is actually
this possible? Best stick with Memo fields?
I don't really want to implement a matrix spanning over many tables of one-to-one
join, unless you claim this is the best way.
e.g;
Table: ResponseMatrix
===========================================
ID | MatrixName | DataType | Data (Currently Memo)
===========================================
1 | Brand | 0 | 1, 43,1,23,45,56,66,.....21
| | | 2, 5,23,456,65,45,.....3
| | | n, .......................
----------------------------------------------------------------
34 | Segments | 0 | another matrix like the above....
----------------------------------------------------------------
56 | Motivation | 1 | another matrix like the above....
----------------------------------------------------------------
77 | .... | ... | another matrix like the
above....
===========================================
C#: OleDb data access layer
C#: Application rules layer
C#: Interface
Would like;
===========================================
ID | MatrixName | DataType | Data (OLEObject)
===========================================
1 | Brand | 0 | 1 43 1 23 45 56 66 ..... 21
| | | 2 5 23 456 65 45 .....3
| | | n .......................
----------------------------------------------------------------
I know I would not see the data in this type of field until extracted.
Thanks and regards,
- Saccess