New keys
            
                
                    Waldo                
                
                    Member Posts: 3,412                
            
                        
            
                    Hi,
I would want your opinion.
I have created two extra indexes? Why? Because my customer is using NAV and Filters in the most exotic way...
The question is in which order you would place the fields... . I know, the most selective, but it's hard to say which are most selective... #-o
Index No. 1 on Sales Line table:
- No.
- Shipment Date
- Outstanding Quantity
- Type
I know No. is good, but what about the other fields?
Index No. 2 on Sales Line table:
- Shipment Date
- Production Group
- Shipment Day
- VendorNr
You would say "vendornr" is quite selective, but it isn't. They filter on it the way that they still get a very large number of records... , same for production group. In fact, the way they filter, you get about en even amount of records for all fields... ](*,) .
Is it a good idea to put a date first?
                I would want your opinion.
I have created two extra indexes? Why? Because my customer is using NAV and Filters in the most exotic way...
The question is in which order you would place the fields... . I know, the most selective, but it's hard to say which are most selective... #-o
Index No. 1 on Sales Line table:
- No.
- Shipment Date
- Outstanding Quantity
- Type
I know No. is good, but what about the other fields?
Index No. 2 on Sales Line table:
- Shipment Date
- Production Group
- Shipment Day
- VendorNr
You would say "vendornr" is quite selective, but it isn't. They filter on it the way that they still get a very large number of records... , same for production group. In fact, the way they filter, you get about en even amount of records for all fields... ](*,) .
Is it a good idea to put a date first?
0                
            Comments
- 
            
In SQL, a date and a time are of type "Datetime", so not really good in an index. So best leave it at the end of the index. Most of the time, I don't even put it in the index because the gain for reading is low and I do gain some speed for writing the index (and not writing the field).Waldo wrote:Index No. 1 on Sales Line table:
- No.
- Shipment Date
- Outstanding Quantity
- Type
I know No. is good, but what about the other fields?
Also a decimal in general is not really good for an index. (Only used it in Navision when I had to sort on it...)
So in this case I would say : "No.","Type" as index. the other fields are of no use (in general).
If you know that you only have 1 Type (e.g. Item), no need to put it in the index.
You can try something for checking if "Shipment Date" is usefull: With the "SQL Server Management Studio" of SQL2005, you can check the selectivity-statistics of the index and if you see that the "shipment date" helps a lot, you can put it in the index. BUT only if you really use it to filter.
First and for all : it is never a good idea to put the date first. (Except, maybe, if you don't have any other filter)Waldo wrote:Index No. 2 on Sales Line table:
- Shipment Date
- Production Group
- Shipment Day
- VendorNr
You would say "vendornr" is quite selective, but it isn't. They filter on it the way that they still get a very large number of records... , same for production group. In fact, the way they filter, you get about en even amount of records for all fields... ](*,) .
Is it a good idea to put a date first?
What field type is Shipment Day? I suppose it is an integer with 7 possible values (1 for each day of the week).
So also this one has not really a big selectivity. So I suppose you can choose between "Vendor No.","Production Group" or "Production Group","Vendor No.".
After these 2 fields, I would say "Shipment Day","Shipment Date" OR "Shipment Day" OR "Shipment Date". This depends if you filter on it or not and how useful it is (see again selectivity-statistics).
How to see selectivity-statistics IN SQL2005 (also useful on a SQL2000!).
Go in the database => table => Statistics => select your key. Doubleclick on it=>another form opens => Details : "All Density"-column. The smaller the number the better.Regards,Alain Krikilion
No PM,please use the forum. || May the <SOLVED>-attribute be in your title!0 - 
            kriki wrote:How to see selectivity-statistics IN SQL2005 (also useful on a SQL2000!).
Go in the database => table => Statistics => select your key. Doubleclick on it=>another form opens => Details : "All Density"-column. The smaller the number the better.
I thought so about the dates, but in fact, the dates do give me some performance gain :-k ...
Thanks for the tip about selectivity. Didn't know that...0 - 
            Yes, dates in indexes can be very usefull. Discovered that again today.

It is always a matter of considerarion. Reads vs. Writes.0 
Categories
- All Categories
 - 73 General
 - 73 Announcements
 - 66.7K Microsoft Dynamics NAV
 - 18.7K NAV Three Tier
 - 38.4K NAV/Navision Classic Client
 - 3.6K Navision Attain
 - 2.4K Navision Financials
 - 116 Navision DOS
 - 851 Navision e-Commerce
 - 1K NAV Tips & Tricks
 - 772 NAV Dutch speaking only
 - 617 NAV Courses, Exams & Certification
 - 2K Microsoft Dynamics-Other
 - 1.5K Dynamics AX
 - 323 Dynamics CRM
 - 111 Dynamics GP
 - 10 Dynamics SL
 - 1.5K Other
 - 990 SQL General
 - 383 SQL Performance
 - 34 SQL Tips & Tricks
 - 35 Design Patterns (General & Best Practices)
 - 1 Architectural Patterns
 - 10 Design Patterns
 - 5 Implementation Patterns
 - 53 3rd Party Products, Services & Events
 - 1.6K General
 - 1.1K General Chat
 - 1.6K Website
 - 83 Testing
 - 1.2K Download section
 - 23 How Tos section
 - 252 Feedback
 - 12 NAV TechDays 2013 Sessions
 - 13 NAV TechDays 2012 Sessions
 
