|
FORUMS PROFESSIONNELS
WINDEV, WEBDEV et WINDEV Mobile |
| | | | | |
| Débuté par Owen, 21 juin 2005 23:51 - 8 réponses |
| |
| | | |
|
| |
Posté le 21 juin 2005 - 23:51 |
Hello All,
I've finished reading all the manuals, did some programming examples, starting reading some of the comments from previous posts. I have a few questions...
Automatic ID's...
I have seen a few people saying not to use them?
Are these limited cases where it corrupts? Or is this a major issue? (Not very reassuring if it is).
Rad... To Rad or not to Rad that is the question?
First off, all this read, write, add, delete control, record locks, empty databases, etc... They should not even have a "RAD" option it should be automatically handled by WinDev. Maybe v10 (Think FileMaker Pro).
Since I'm used to having all these items delt with and seeing all these posts some for, some against. What are the issuse with using it? besides being a little over kill and not fully "RAD". Those that are, are you using procedural code or OOC?
Thanks,
Owen |
| |
| |
| | | |
|
| | |
| |
Posté le 22 juin 2005 - 01:23 |
Hello All,
I've finished reading all the manuals, did some programming examples, starting reading some of the comments from previous posts. I have a few questions...
Automatic ID's...
I have seen a few people saying not to use them?
Are these limited cases where it corrupts? Or is this a major issue? (Not very reassuring if it is).
Rad... To Rad or not to Rad that is the question?
First off, all this read, write, add, delete control, record locks, empty databases, etc... They should not even have a "RAD" option it should be automatically handled by WinDev. Maybe v10 (Think FileMaker Pro).
Since I'm used to having all these items delt with and seeing all these posts some for, some against. What are the issuse with using it? besides being a little over kill and not fully "RAD". Those that are, are you using procedural code or OOC?
Thanks,
Owen
Hi Owen,
I do not use any auto-IDs, but not because of their possible crashing. I think, they're just not useful - in my programs. I surely believe that an Auto-ID must be useful somewhere, therefore is PC Soft offering such an item. I just cannot imagine where ... but maybe I'm a bit stupid?
RAD. I think that RAD is very useful - again, you guessed it: in my programs. You cannot use RAD without doing some extensive researches. You have to set up the user interface of your program to be and you have to set the rules. All of that before starting to build the analysis. RAD is not useful for small programs or special utilities. But RAD is definitely useful in big ERP or CRM software. So, it depends .. I decided to use SDI-interface with procedural code and multi-user.
Regards,
Guenter |
| |
| |
| | | |
|
| | |
| |
Posté le 22 juin 2005 - 02:27 |
G'day Owen
I only used RAD to learn about Windev and would not use it in production, but haven't seen version 9 RAD yet, so it may offer great things. I don't like to work within the confines of a RAD Framework and have developed my own quick development methods using global procs, and data and parameter driven screens.
I use auto-ids on every file as the primary key and then as foreign keys in child files and would not program without them. There have been a few very minor problems with them, but are insignificant compared to manually maintaining primary key integrity in even a small data set.
Regards
Al |
| |
| |
| | | |
|
| | |
| |
Posté le 22 juin 2005 - 02:58 |
G'day Owen
I only used RAD to learn about Windev and would not use it in production, but haven't seen version 9 RAD yet, so it may offer great things. I don't like to work within the confines of a RAD Framework and have developed my own quick development methods using global procs, and data and parameter driven screens.
I use auto-ids on every file as the primary key and then as foreign keys in child files and would not program without them. There have been a few very minor problems with them, but are insignificant compared to manually maintaining primary key integrity in even a small data set.
Regards
Al
Hi Al, just two questions regarding auto-IDs:
Example 1: A file with customer records. A customer can be found by customer number, by name, by zip-code and so on. What good is an auto-ID here?? The auto-ID can, at best, tell us something about the sequence of the original input of data. The customer number is unique key anyway. You can force the name field being a unique item as well.
Example 2: You have a customer file with a relation to a payment condition file. Each record is a payment condition. I prefer to number payment conditions 1,2,3, ...12,13.. and sort the combo by this number. In case you are having an auto-ID for the payment cond. file: If you are inputting 30 customers per day and the records of the payment condition file are to be added, deleted and changed frequently, as a result those persons inputting new customers would find the payment condition they are searching for always in another position in that combo box. The same would happen if the text item of the payment condition is taken as a sort item for the combo. I cannot see the advantage of an auto-ID, to me, it seems to be rather disadvantageous in this case.
Maybe, you can shed some light ...?
Regards,
Guenter
Version 9 RAD has been improved over V8 RAD a bit. Not a lot. |
| |
| |
| | | |
|
| | |
| |
Posté le 22 juin 2005 - 04:29 |
I use auto-ids on every file as the primary key and then as foreign keys in child files and would not program without them. There have been a few very minor problems with them, but are insignificant compared to manually maintaining primary key integrity in even a small data set.
Regards
Al
Hi Al, just two questions regarding auto-IDs: Example 1: A file with customer records. A customer can be found by customer number, by name, by zip-code and so on. What good is an auto-ID here?? The auto-ID can, at best, tell us something about the sequence of the original input of data. The customer number is unique key anyway. You can force the name field being a unique item as well. Example 2: You have a customer file with a relation to a payment condition file. Each record is a payment condition. I prefer to number payment conditions 1,2,3, ...12,13.. and sort the combo by this number. In case you are having an auto-ID for the payment cond. file: If you are inputting 30 customers per day and the records of the payment condition file are to be added, deleted and changed frequently, as a result those persons inputting new customers would find the payment condition they are searching for always in another position in that combo box. The same would happen if the text item of the payment condition is taken as a sort item for the combo. I cannot see the advantage of an auto-ID, to me, it seems to be rather disadvantageous in this case. Maybe, you can shed some light ...? Regards, Guenter Version 9 RAD has been improved over V8 RAD a bit. Not a lot.
Thanks for the replies.
Al, What do you mean by minor problems? Wish to elaborate?
Gunter, not sure I'm following how creating the number manually vs automatically would change. Unless you are renumbering upon deleting a record, so there is no gap in numbers?
Owen |
| |
| |
| | | |
|
| | |
| |
Posté le 22 juin 2005 - 06:26 |
G'day Owen
The only problem I have ever had with the auto-id is on about 3 or 4 occasions, after a bad shutdown, the database file has refused to allow the addition of new records. I assumed this was due to a corruption of the header record and in each case I was able to fix the problem by manually adding a record with wdmap.
Regards
Al |
| |
| |
| | | |
|
| | |
| |
Posté le 22 juin 2005 - 16:11 |
G'day Guenter
I think the distinction needs to be made between auto-ids and primary keys. Windev provides a mechanism to create a unique number for record. I could also manually create a unique number for each record. However this number is derived, I use it as a primary key, but I find the Windev auto-id the best way to create this number. It was in that context that I answered Owens question -
Automatic ID's...
I have seen a few people saying not to use them?
Are these limited cases where it corrupts? Or is this a major issue?
In answer to your questions.
>Example 1: A file with customer records. A customer can be found by customer number, by name, by zip-code and so on. What good is an auto-ID here?? The auto-ID can, at best, tell us something about the sequence of the original input of data. The customer number is unique key anyway. You can force the name field being a unique item as well.
I use the auto-id as the primary key in a parent so it can be used as a foreign key in a child database. It is very rarely used as a lookup by the user as in most cases they are unaware of its existence. I still use the customer code or name etc to lookup the customer but I would only look up customer child records using the customer primary key as a foreign key in each child record
I appreciate that Windev8 will do a cascading change but with separate primary key links this is not required, you simply change the customer code or name in the customer file and you can do this because it is not being used as the link value. Auto-id's used as primary keys eliminate redundant data in child files and allow databases to be normalized. Having said that I still occasionally break all the rules because if you are at the lowest rung of a 6 level relationship, it can be pretty time consuming to traverse all the way back to the top using primary and foreign keys.
Regards
Al |
| |
| |
| | | |
|
| | |
| |
Posté le 22 juin 2005 - 16:33 |
Hallo Al,
you are right - you can make your own ID or Windev can make the job. But we have found ( sometimes ) in the auto ID from Windev :
- duplicated keys
- jumps from 1000 to 8000000
- corrupted index more then for our other indexes
- not possible to add new records
( never change any ID by programming ! )
No expirience with own auto ID, but we think to change and test this.
Christoph
G'day Guenter I think the distinction needs to be made between auto-ids and primary keys. Windev provides a mechanism to create a unique number for record. I could also manually create a unique number for each record. However this number is derived, I use it as a primary key, but I find the Windev auto-id the best way to create this number. It was in that context that I answered Owens question - Automatic ID's...
I have seen a few people saying not to use them?
Are these limited cases where it corrupts? Or is this a major issue?
In answer to your questions. Example 1: A file with customer records. A customer can be found by customer number, by name, by zip-code and so on. What good is an auto-ID here?? The auto-ID can, at best, tell us something about the sequence of the original input of data. The customer number is unique key anyway. You can force the name field being a unique item as well.
I use the auto-id as the primary key in a parent so it can be used as a foreign key in a child database. It is very rarely used as a lookup by the user as in most cases they are unaware of its existence. I still use the customer code or name etc to lookup the customer but I would only look up customer child records using the customer primary key as a foreign key in each child record I appreciate that Windev8 will do a cascading change but with separate primary key links this is not required, you simply change the customer code or name in the customer file and you can do this because it is not being used as the link value. Auto-id's used as primary keys eliminate redundant data in child files and allow databases to be normalized. Having said that I still occasionally break all the rules because if you are at the lowest rung of a 6 level relationship, it can be pretty time consuming to traverse all the way back to the top using primary and foreign keys. Regards Al |
| |
| |
| | | |
|
| | |
| |
Posté le 22 juin 2005 - 20:02 |
Al
I concur wholly with what you have said
Thanks for giving a very clear reason for your use of this approach
I changed over to this strategy years ago when I moved form PICK/Universe/Revelation type dbs to MS Access. SQL theory back then was largely based on the maths of SET theory, and it said that you should use real keys hence the evolvement of multipart keys and all joys and sorrows that go with them
It was very hard on the mind to make the change back then because it went against all that I had learned but it was one of the best decisions I made. As you say it frees you up from the constraints of the data. Joe Celko (SQL guru) wrote a paper on it and said something like “Create surrogate keys in your main files and designate them as the primary key, then use them as foreign keys in all related files” He admitted that although this breaks certain SQL rules it was hugely expedient and beneficial without really ruining the whole concept data normalisation
What I have found is that it hugely increases the speed of SQL Query execution at the point of joins, because u are not using complex multipart keys. Now when you get to the presentation layer that the end user interacts with then you can use all the clever searching on multipart fields etc that WD facilitates
It also makes it so much easier to fix any corrupted cross files etc. Also by not resorting to cascading updates on key fields u avoid one more area of potential failure, esp with a file based db. There is one caveat; u need to implement your own checking for duplicate names for instance in a customer file, but that’s easy using triggers or similar
http://www.objeKtive.com |
| |
| |
| | | |
|
| | | | |
| | |
| | |
| |
|
|
|