My replies are scattered around your questions.


>Cetin,
>
>Is it really you? I would not expect such an reply from you. I'd thought you knew better.

Yes, it is really me, had an heart attack 1-2 years back, but still alive and in good condition now. I don't understand what you expected me to know better, sorry.


>
>First of all, I can't remember the time I worked with FOX2X or FREE tables which have a 10 character issue. Fields coming from SQL server and from tables in a DBC do not have such issue so it is not an issue at all. Really if we are talking about development where we are still bound to 10 characters I think the is no discussion possible: I can't see why anyone would still go that route.

Where did I ever mentioned 10 characters issue (although it is still an issue that you shouldn't overlook I didn't mention it at all, did I?).


>
>As for your argument about mdot and the three character Prefix. That one is very easy. The mdot does not carry any information about the variable to me. The three letter prefix does carry very important information namely from which table it comes from.


That is a very wrong statement. m. does carry one most important information for not only you the developer but to the compiler\interpreter as well and that is as you well know to tell that the variable IS as memory variable. Three letter prefix doesn't have any importance to me. It is simply redundancy. Alias your variables and you would know from which table it comes from if you don't.
Why would I have ord or order or ord_ or anything like that for a field named OrderDate??? Should I rename it to be ord_Date? Then what about ShippedDate? Why should you ever expect to have customers.ShippedDate and even if I had simply I know by its alias. Aliases are already part of the convention for database tables, why would I add another layer at all. customers.cus_CompanyName doesn't make sense to me and it is really unreadable from my viewpoint.

And also having intellisense support using mdot is by itself a valuable information (apart from also saving keystrokes).


>
>Consider you have a doctors table and a patient table.
>Both would have a column 'Name'
>
>if you have a query to list patients and their doctors your SQL will have rename the columns to avoid ambiguity.

Very true and you would really want to do that.

>You don't have to do this in my case because the columns would have different names: PAT_NAME and DOC_NAME . There could be no confusion where this field comes from anywhere in you code, whether VFP or SQL querys because the name of the field is unique in the database. This adds to the readability of your code, not having to guess what the field 'Name' refers to.

No, that is an assumption that it adds any readability. For me it is something that hurts my eyes. If I wanted have it like that, I could have the fields named PatientName and DoctorName initially or later at runtime. You are saying there wouldn't be any confusion anywhere in the code. What if you needed to refer to the same table and field more than once? In real life I have it. i.e. The employee who got the order and who made the sale might be different:

Customer: Name
Employee: Name
Order: Customer, EmployeeWhoEnteredOrder, EmployeeWhoMadeTheSale

What would you do, no confusion now? With your "no confusion" approach it would be like:

cus_Name, emp_Name, emp_Name

Oops.

OTOH I could simply alias them and rename the resultant fields:

cus.Name as Customer, oe.Name as OrdEmp, sl.Name as Salesman from Customers cus ... employee oe ... employee sl

>
>>Hard to understand why would I ever want to name a field ord_OrderDate (maybe helping to prevent cus_OrderDate?) Ugly and readable, go figure. They surely help unnecessarily typing 3-4 more letters per fieldname.
>
>The field would just be named: ORD_DATE not ORD_ORDERDATE. The prefix tells you the identity of the table so no need to repeat that in the rest of the column name.

Really???? What is that date about? The date ordered, or when it is shipped or what? I already said this above. It doesn't carry information other than it is a field named DATE on ORDERS table (hmm really? is it Orders, orderHeader, orderDetail ...? maybe we need 3+ char table prefixes).

>
>Other implications:
>
>Each table will have a PK field fromatted as XXX_PK and foreign keys can be formated as CCC_PPPFK (C= Child prefix table, P = Parent prefix table), so
>
>ORD_CUSFK = Forgeign key from the orders table to the customers table
>PAT_DOCFK = Reference to the patients doctor
>

Oh my God. Naming convention is making it worse. I would never want to have such naming in my code. We could agree I would never be eligible to work within your organisation.

>It makes it very clear, also in code, what this field means and what it refers to. Als long as there are duplicate fields no self join in the query, there is no need to rename fields when having a naming conflict and therefore all the fields referenced in code are having the same name as the fields where they originate from. A huge bonus as no matter what code I look at, the fieldname always is going to tell me what it is and where it comes from.

No, that is just an assumption that you believe. Whether on parent or child, a PK or FK field simply could have the pattern ID and tableNameID or tableNameID on both. i.e.:

customers.ID and SalesHeader.CustomerID
or:
customers.customerID and SalesHeader.CustomerID (and contacts.CustomerID or any table that would refer to it).

I even don't want to think about multi key PK and FKs with your pattern.

And mind you, this ID - tableNameID convention is used by many languages, generator tools as "convention" to generate relations. What if your nice table that does use Ord_PK would also be accused from another language, tool? (It might be you who also code in that language so you are in fact should think yourself).


>
>And if not using GUIDS or IDENTITY columns but relying on a number generator you can use the fieldname you're generating a number for as a key, as it is unique.
>If you want to store metadata of fields for the purpose of validation, capitlisation, formatting etc you can do so by simply taking the fieldname regardless under which alias the view or table is opened.
>And there are other advantages we created on having a unique fieldname in the database, like creating ad-hoc updatable views where we can use a hint like 'ORD_*' to indicate that only all fieldname beginning with ORD_ are to be updatable, audit trail functionality etc.
>
>I began using this naming convention suggested to me about 20 years ago and never looked back. I cannot find any reason to do so, esspecially when having databases with large number of tables.
>Several big companies use this or simular naming convention (e.g. wikipedia) so this is not a quirk that is rare. See https://www.codeproject.com/Articles/22947/A-Naming-Scheme-for-Database-Tables-and-Fields for more arguments.
>
>Like all naming convention discussion, this for a significant part has to do with unfamiliarity and personal preference, and too often fall in the category 'holy wars'

Having something in wikipedia doesn't mean it is the right thing to do. Hungarian notation is also on wikipedia, no? Something sticked to VFP developers from hell. Today I am still using it, why, because it is worth a penny carrying information? No. Using because I post code on the forums and it is in use by the community. Luckily in other languages I work with, developers don't have such an ugly and redundant naming.

You have adopted that convention to yourself and you might personally find it useful. I don't.

What I am simply telling is mdot is a defined component of the language. It explicitly tells the compiler that it IS a memory variable, while no naming convention could have such an impact on the compiler.

Up to this date, no one developer could show me a piece of demo code that using mdot could make any harm. I did demo the reverse N times and bored of this to be seen as a holy war rather than being simply part of the language. I do and will always use mdot. If you see a code from me without mdot, that is just because it is an old code from my archive written when I wasn't aware of mdot's virtues enough (namely around when VFP7 came) and not edited since then.