|
Glad to see this thread, and I hope I can contribute something useful here and there. And now, my plea for sympathy: I support a vertical market software package that is based on multiple Microsoft Access databases accessed via Jet 3.0 and programmed in Visual Basic 6. The amount of bullshit I have to put up with on a daily basis keeping up the slices of swiss cheese that are my clients' databases makes me want to  On the plus side, I have learned a great deal about SQL in a short period of time and within the next year we will be migrating to a SQL Server 2005 Express platform.  Edit: Golbez, I have a great deal of problems due to Jet 3 being ridiculously inefficient with anything beyond a simple SELECT...especially over a network. Can I assume that using indexed fields in my queries will speed that up? I do notice that JOINs are almost always faster than a nested query... Powdered Toast Man fucked around with this message at 19:21 on Nov 27, 2007 |
#
¿
Nov 27, 2007 19:19
|
|
|
|
| # ¿ Apr 29, 2024 02:48 |
|
|
Is a "link table" the only way to handle a many-to-many relationship? I'm creating a database to keep track of job title <--> active directory group membership information and that's obviously many-to-many. I'm also a bit stuck on how to process the information I have available to get it into the database. Presently, it resides in a crappy Excel workbook. It is easily exported, but the relationships are another matter. Right now the Excel workbook keeps track of those by using a hidden sheet that has a column for each job title, and then each group that is associated with that title is listed under that column (with the title itself at the top). I'm planning to go from Excel 2007 to Access 2007...it's what I have available and I have some experience with Access, so whatever. Any ideas?
|
|
#
¿
Apr 10, 2012 23:15
|
|
|
Having a bit of difficulty; I'm new to T-SQL and my general SQL skills are a bit rusty after a long time not being used... I'm dealing with AD objects, specifically groups (both security and distribution). To ensure accuracy, I am using their SIDs as the primary key. The group display name is still important, though, because the results need to be readable by a person, and also because I have a bunch of data that is organized by the display name rather than the SID of the group. Essentially I need to build a link table relating each job title in the company to its associated security and distribution groups. I have taken this data out of a previously used spreadsheet and it is formatted something like this (where each item is a column): JobTitle, Group1, Group2, Group3, ... The contents of each group column differ depending on the job title. Some jobs have only a few groups, some have as many as 30. So, each JobTitle/Groupn pair is a relationship that needs to go into my link table. I have the groups associated to their SIDs in another table. I have each job title associated with an ID in another table. I want to take the information in the GroupsToTitles table and turn it into a link table associating the job title ID with the SID for the group. I know how to do joins, but I'm really struggling with the mechanics of this. Would it be better to try to process one column at a time in the GroupsToTitles table or can it be done all at once? I just need a nudge in the right direction, here. Sorry if that was a bit rambling, I hope it made sense.
|
|
#
¿
Apr 24, 2012 15:35
|
|