16,014,392 members
Sign in
Sign in
Email
Password
Forgot your password?
Sign in with
home
articles
Browse Topics
>
Latest Articles
Top Articles
Posting/Update Guidelines
Article Help Forum
Submit an article or tip
Import GitHub Project
Import your Blog
quick answers
Q&A
Ask a Question
View Unanswered Questions
View All Questions
View C# questions
View C++ questions
View Javascript questions
View Visual Basic questions
View .NET questions
discussions
forums
CodeProject.AI Server
All Message Boards...
Application Lifecycle
>
Running a Business
Sales / Marketing
Collaboration / Beta Testing
Work Issues
Design and Architecture
Artificial Intelligence
ASP.NET
JavaScript
Internet of Things
C / C++ / MFC
>
ATL / WTL / STL
Managed C++/CLI
C#
Free Tools
Objective-C and Swift
Database
Hardware & Devices
>
System Admin
Hosting and Servers
Java
Linux Programming
Python
.NET (Core and Framework)
Android
iOS
Mobile
WPF
Visual Basic
Web Development
Site Bugs / Suggestions
Spam and Abuse Watch
features
features
Competitions
News
The Insider Newsletter
The Daily Build Newsletter
Newsletter archive
Surveys
CodeProject Stuff
community
lounge
Who's Who
Most Valuable Professionals
The Lounge
The CodeProject Blog
Where I Am: Member Photos
The Insider News
The Weird & The Wonderful
help
?
What is 'CodeProject'?
General FAQ
Ask a Question
Bugs and Suggestions
Article Help Forum
About Us
Search within:
Articles
Quick Answers
Messages
Comments by FastEvo8 (Top 8 by date)
FastEvo8
8-Dec-11 23:08pm
View
I am surprised to hear that it takes 3-4 minutes to retrieve one record with only 30-40k records. I am starting to think that you might have other issues on your server that are slowing down your query.
Why don't you create the index for the column name?
Did you check the query plan?
Are the data types of the emp_ID fields the same?
Do you have a one to one or a one to many relationship?
FastEvo8
8-Dec-11 17:01pm
View
I do not agree.
the FK relationship is used for keeping the referential integrity in the database and has nothing to do with indexing. As a matter of fact it may slow down inserts since the DB engine will check if the new values exists in the parent table (check the query plan and you will see it),
FastEvo8
8-Dec-11 13:56pm
View
It is very difficult to troubleshoot your performance issue with the limited info you are supplying.
What do you mean by "Huge table"...do you have a 1 billion records?
Indexes are meant to speed up searches, if you do no have one you might want to consider to add it.
What is the query you are running?
Please try to provide more details.
FastEvo8
6-Dec-11 13:59pm
View
Where are @PrefijoPapel AND @FolioPapel coming from?
Are they in a table?
FastEvo8
28-Oct-11 9:25am
View
I totally agree, "Select *" needs to be avoided.
Selecting only the data you need is your first performance improvement hint!
FastEvo8
19-Oct-11 15:00pm
View
Well said Marcus.
I will also add that trying to reorder the table could become a concurrency nightmare and a performance issue.
FastEvo8
7-Oct-11 16:07pm
View
In that case when you read the data from the table you should use the RANK() function:
SELECT g.GymMemeberID,
RANK() OVER (PARTITION BY g.GymMemeberID ORDER BY l.Log#) AS LogNumber, *
FROM GymMember g
INNER JOIN Log l
ON g.GymMemberID=l.GymMemberID
FastEvo8
7-Oct-11 14:39pm
View
This way you do not need the linking table.
If you had a many to may relationship than you would need it.
Make sure that you add the field GymMemberId in the log table and add the FK constraints ( last step is optional,but it is recommended otherwise you need to manage relationship integrity)
Show More