ideas please
-
Hello, I am new to database programming (actually, I am not started yet). I am recording some data in real-time (voice). Now I need to allow the user for searching for some data given a specific time. I was told that I should consider using SQL, or DAO or ODBC. I have no clue what the best thing to use is. So I am looking for some information. Any suggestion will be largely appreciated. Thanks a lot. Where there is a WISH, there is a WILL.
-
Hello, I am new to database programming (actually, I am not started yet). I am recording some data in real-time (voice). Now I need to allow the user for searching for some data given a specific time. I was told that I should consider using SQL, or DAO or ODBC. I have no clue what the best thing to use is. So I am looking for some information. Any suggestion will be largely appreciated. Thanks a lot. Where there is a WISH, there is a WILL.
This isn't a complete solution, but should help you get started. 1. First you need establish the database requirements. e.g. exactly what do you need to store, search, retrieve from your DB. How big are the images, how many, etc. 2. With that in hand, select a database engine. There are many, each has its own strengths, weaknesses and costs. Oracle and SQL server are enterprise databases. They are beefy and very capabley (expensive). Access is good for smaller or simpliler applications. May others also exist. 3. Create the actual database schema (you don't need to populate it, just define it). 4. Finally ready to start designing/coding the app. At this point you can select accessing technologies. The main ones available are ODBC, DAO, ADO. ADO is the current favorite. If this is a significant application, you may want to consult a DB expert to help you design your database and select a db engine. Hope this helps, Bill
-
This isn't a complete solution, but should help you get started. 1. First you need establish the database requirements. e.g. exactly what do you need to store, search, retrieve from your DB. How big are the images, how many, etc. 2. With that in hand, select a database engine. There are many, each has its own strengths, weaknesses and costs. Oracle and SQL server are enterprise databases. They are beefy and very capabley (expensive). Access is good for smaller or simpliler applications. May others also exist. 3. Create the actual database schema (you don't need to populate it, just define it). 4. Finally ready to start designing/coding the app. At this point you can select accessing technologies. The main ones available are ODBC, DAO, ADO. ADO is the current favorite. If this is a significant application, you may want to consult a DB expert to help you design your database and select a db engine. Hope this helps, Bill
>This isn't a complete solution, but should help you get started. Ok. Let's see ... >1. First you need establish the database requirements. e.g. exactly what do you need to store, search, retrieve from your DB. How big are the images, how many, etc. I need to store sound files (wav, ...) with a date and time associated to every piece of data that represent 1 seconde of sound. The user can then search for a sound that have been recorded at a specific time. The program records continuously ... so I have a very large quantity of informations. >2. With that in hand, select a database engine. There are many, each has its own strengths, weaknesses and costs. Oracle and SQL server are enterprise databases. They are beefy and very capabley (expensive). Access is good for smaller or simpliler applications. May others also exist. I'm thinking about SQL servers. It sounds that it is more portable and robust. And once you know how it works, you have no problem switching to another one. QUESTION: Are these free? or do I have to by something? >3. Create the actual database schema (you don't need to populate it, just define it). Ok. >4. Finally ready to start designing/coding the app. At this point you can select accessing technologies. The main ones available are ODBC, DAO, ADO. ADO is the current favorite. I read a little about these technologies. I am more thinking about using ODBC. It sounds that I is faster than DAO (if I don't use Access database). Also, my database will be on a remote computer. I read that ODBC is more efficient in this case. >If this is a significant application, you may want to consult a DB expert to help you design your database and select a db engine. This really is a significant application. I am used to get things done by reading, asking questions, prototyping, ... Do you think that these are things we can't learn on the fly ? >Hope this helps, >Bill This helped a lot. Thank you very much. Where there is a WISH, there is a WILL.
-
>This isn't a complete solution, but should help you get started. Ok. Let's see ... >1. First you need establish the database requirements. e.g. exactly what do you need to store, search, retrieve from your DB. How big are the images, how many, etc. I need to store sound files (wav, ...) with a date and time associated to every piece of data that represent 1 seconde of sound. The user can then search for a sound that have been recorded at a specific time. The program records continuously ... so I have a very large quantity of informations. >2. With that in hand, select a database engine. There are many, each has its own strengths, weaknesses and costs. Oracle and SQL server are enterprise databases. They are beefy and very capabley (expensive). Access is good for smaller or simpliler applications. May others also exist. I'm thinking about SQL servers. It sounds that it is more portable and robust. And once you know how it works, you have no problem switching to another one. QUESTION: Are these free? or do I have to by something? >3. Create the actual database schema (you don't need to populate it, just define it). Ok. >4. Finally ready to start designing/coding the app. At this point you can select accessing technologies. The main ones available are ODBC, DAO, ADO. ADO is the current favorite. I read a little about these technologies. I am more thinking about using ODBC. It sounds that I is faster than DAO (if I don't use Access database). Also, my database will be on a remote computer. I read that ODBC is more efficient in this case. >If this is a significant application, you may want to consult a DB expert to help you design your database and select a db engine. This really is a significant application. I am used to get things done by reading, asking questions, prototyping, ... Do you think that these are things we can't learn on the fly ? >Hope this helps, >Bill This helped a lot. Thank you very much. Where there is a WISH, there is a WILL.
"QUESTION: Are these free? or do I have to by something?" No not free. :(( "This really is a significant application. I am used to get things done by reading, asking questions, prototyping, ... Do you think that these are things we can't learn on the fly ?" No, they aren't. You can, with considerable effort, become a novice DB developer. To go beyond that requires education/experience. If this application is commercial or even IT production, you will be doing yourself a favor to get a professional involved. If it turns out to not be very complicated, it won't cost much. Hope this helps, Bill
-
"QUESTION: Are these free? or do I have to by something?" No not free. :(( "This really is a significant application. I am used to get things done by reading, asking questions, prototyping, ... Do you think that these are things we can't learn on the fly ?" No, they aren't. You can, with considerable effort, become a novice DB developer. To go beyond that requires education/experience. If this application is commercial or even IT production, you will be doing yourself a favor to get a professional involved. If it turns out to not be very complicated, it won't cost much. Hope this helps, Bill
Ok. You helped me a lot. That's just too bad you don't accept credit cards :rolleyes: I thank you again. Actually, I am a software engineer with 5 years experience in programming realtime systems. I also used to be an analyst-programmer (Dbase IV) for 2 years. But things changed since then. Just to say that I have some notions in programming. After reading your suggestions, I think that I'll implement my own database (binary file with my own format). I only have one thread writing informations to the database while another thread have a read-only access to this database. Take care. Where there is a WISH, there is a WILL.
-
>This isn't a complete solution, but should help you get started. Ok. Let's see ... >1. First you need establish the database requirements. e.g. exactly what do you need to store, search, retrieve from your DB. How big are the images, how many, etc. I need to store sound files (wav, ...) with a date and time associated to every piece of data that represent 1 seconde of sound. The user can then search for a sound that have been recorded at a specific time. The program records continuously ... so I have a very large quantity of informations. >2. With that in hand, select a database engine. There are many, each has its own strengths, weaknesses and costs. Oracle and SQL server are enterprise databases. They are beefy and very capabley (expensive). Access is good for smaller or simpliler applications. May others also exist. I'm thinking about SQL servers. It sounds that it is more portable and robust. And once you know how it works, you have no problem switching to another one. QUESTION: Are these free? or do I have to by something? >3. Create the actual database schema (you don't need to populate it, just define it). Ok. >4. Finally ready to start designing/coding the app. At this point you can select accessing technologies. The main ones available are ODBC, DAO, ADO. ADO is the current favorite. I read a little about these technologies. I am more thinking about using ODBC. It sounds that I is faster than DAO (if I don't use Access database). Also, my database will be on a remote computer. I read that ODBC is more efficient in this case. >If this is a significant application, you may want to consult a DB expert to help you design your database and select a db engine. This really is a significant application. I am used to get things done by reading, asking questions, prototyping, ... Do you think that these are things we can't learn on the fly ? >Hope this helps, >Bill This helped a lot. Thank you very much. Where there is a WISH, there is a WILL.
Djibril wrote: I need to store sound files (wav, ...) with a date and time associated to every piece of data that represent 1 seconde of sound. The user can then search for a sound that have been recorded at a specific time. The program records continuously ... so I have a very large quantity of informations. Wait, I think the selection of a database is the least of your worries! Do you really want to store 1 second clips ?? In order to play a 10 second piece, you have to retrieve 10 1-sec clips using SQL SELECT, squish them together (how?), then play the 10 sec clip. It is quite a challenge in compressed formats like MP3. It may be simple in WAV but note that WAV is an uncompressed format. It will eat up your storage in no time. I dont know the background of your project, but it sounds like (no pun intended ;-) ) a streaming input with a non-streaming output system. I suggest you store incoming stream in 1-2 hr chunks of compressed format, such as MP3. Then use a player such as Winamp to skip to a location.