[LØST] - MSSQL - Flere treff pr post

[bjornawarjar]

Har en mssql-database som er ment å fungere som produktregister.

 

Relevant for dette problemer:

Jeg har tre tabeller i en relasjon: Produkter, Kampanjer og Kamp_Prod som løser opp en mange-til-mange-relasjon mellom Produkter og Kampanjer.

 

Problemet er at når jeg slår opp i databasen, får jeg ett treff på hvert produkt for hver post dette er med i i Kamp_Prod.

Er ProduktID relatert til én KampanjeID kommer dette én gang. Er ProduktID realtert til to KampanjeID kommer det opp TO ganger osv.

 

Dette tilsier jo at det kommer opp mange flere søkeresultater enn nødvendig.

 

Har sett over alle relasjoner, har prøvd å skrive om sql-setningen, men ingenting hjelper.

Kjørt meg litt fast

 

Noen som har en idé om hvor feilen ligger?

Endret 13. november 2007 av bjornawarjar

[Manfred]

SELECT DISTINCT(ProduktID), ...

[bjornawarjar]

Fikk jeg en feilmelding først:

 

Microsoft OLE DB Provider for SQL Server error '80040e14'

 

The text, ntext, or image data type cannot be selected as DISTINCT.

 

Men etter litt omskriving fungerer det som en drøm.

 

 

TAKK!

Endret 13. november 2007 av bjornawarjar

[roac]

Du har hadde ikke productid som text/ntext/varchar(max)/nvarhar(max) eller tilsvarende?

[bjornawarjar]

Alle primærnøkler og fremmednøkler er gjennomgående bigint i denne databasen.

[roac]

Bah, det var jeg som så feil i feilmeldingen også Nuvel. Nå skal jeg ikke legge meg alt for mye opp i hvordan du/dere jobber, men generelt vil jeg si at den datatype alltid skal være den minste som er garantert stor nok. Så for f eks norske poststeder ville jeg brukt en smallint, som er vesentlig mindre enn bigint. Avhengig av radstørrelse så kan en slik endring potensielt føre en reduksjon av antall brukte datablokker med inntil 50%.

Endret 13. november 2007 av roac

[Manfred]

Bah, det var jeg som så feil i feilmeldingen også Nuvel. Nå skal jeg ikke legge meg alt for mye opp i hvordan du/dere jobber, men generelt vil jeg si at den datatype alltid skal være den minste som er garantert stor nok. Så for f eks norske poststeder ville jeg brukt en tinyint, som er vesentlig mindre enn bigint. Avhengig av radstørrelse så kan en slik endring potensielt føre en reduksjon av antall brukte datablokker med inntil 50%.

På norske poststeder bruker jeg alltid CHAR(4), rett og slett på grunn av den første nullen i postnummer her i Oslo. Slå meg gjerne, men jeg synes det er enklere å jobbe med

[j000rn]

Så for f eks norske poststeder ville jeg brukt en tinyint, som er vesentlig mindre enn bigint.

 

Litt sært å begrense det til absolutt indre Oslo vel? Tilogmed jeg som bor på Majorstua har for høyt postnummer...

 

Skrivefeil som skulle vært smallint, men uansett moro å kunne pirke på eksperten her inne

[roac]

Skulle vært smallint ja. Og jeg vil ikke bruke char(4) som primærnøkkel, for postnumre endres i ny og ne. Primærnøkler bør så langt det lar seg gjøre være statiske. Og en ting er at verdiene kan endres, men hva når (for jeg regner med at det skjer) vi går over til femsifrede postnumre? Da vil det bli svært "artig" å ha char(4) som primærnøkkel

 

Men for all del, skrivefeil kommer tuslende i ny og ne, spesielt når man har det travelt på jobben samtidig

[kaffenils]

Her er en grei leveregel: Så lenge du ikke skal utføre aritmetiske operasjoner (+-*/ etc) på verdien så bruk en datatype som lagrer tekst. Dvs. char, varchar, nchar, nvarchar.

[roac]

Her er en grei leveregel: Så lenge du ikke skal utføre aritmetiske operasjoner (+-*/ etc) på verdien så bruk en datatype som lagrer tekst. Dvs. char, varchar, nchar, nvarchar.

Siden vi snakker om tallverdier så skal det i hvert fall ikke være nchar/nvarchar. Hah, der fikk jeg tatt igjen Men personlig lever jeg etter en annen regel: Dersom det er snakk om tall som kan ha leading zero så bruker jeg strengdatatyper, ellers bruker jeg heltallstyper da disse tar mindre plass. Men vi mener vel omtrent det samme

[kaffenils]

Siden vi snakker om tallverdier så skal det i hvert fall ikke være nchar/nvarchar. Hah, der fikk jeg tatt igjen

 

Nå var det postnummeret jeg spesifikt refererte til, så jeg står fortsatt ubeseiret :!:

 

Skjer det forresten noe i Oslo på mandag og tirsdag neste uke? Skal nemlig på kurs hos Microsoft (SQL Server 2005 Performance and Tuning (expert level)). Vi hadde noen premier support timer igjen som vi byttet inn i et kurs. Noen som vil ta en pils eller to?

Endret 13. november 2007 av kaffenils

[j000rn]

Skjer det forresten noe i Oslo på mandag og tirsdag neste uke? Skal nemlig på kurs hos Microsoft (SQL Server 2005 Performance and Tuning (expert level)). Vi hadde noen premier support timer igjen som vi byttet inn i et kurs. Noen som vil ta en pils eller to?

 

Har du mer info/url om det kurset? Jeg regner med at det ikke er stanard MOC kurs, men noe litt mer interesant?

Endret 13. november 2007 av jorn79

[roac]

Postnummer skal i hvert fall ikke være nchar eller nvarchar. char ja, ikke nchar. Det er overhodet INGEN grunn til å bruke unicode for noe som kun inneholder sifre

[kaffenils]

Postnummer skal i hvert fall ikke være nchar eller nvarchar. char ja, ikke nchar. Det er overhodet INGEN grunn til å bruke unicode for noe som kun inneholder sifre

 

Ok så skrev jeg innlegget uten å tenkte meg helt om

[kaffenils]

du mer info/url om det kurset? Jeg regner med at det ikke er stanard MOC kurs, men noe litt mer interesant?

 

Har ingen URL, kun en mail fra Chato Muller hos Microsoft. Jeg ble kontaktet av en av våre avdelingsledere om jeg kunne tenke meg å delta. Hvor ha fikk informasjonen fra vet jeg ikke.

 

Her er uansett innholdet i mailen pluss et pdf-vedlegg om agenda:

 

Hi,

 

 

 

As your Technical Account Manager (TAM) / Application Developer Consultant (ADC), I wish to invite you to this 3 days training with focus on SQL Server 2005 and performance tuning.

 

 

 

Agenda: Full agenda in English is attached. This class is the perfect follow up training if you attended our SQL Server 2005 Performance and Optimization on November 12-15.

 

 

 

Goal of the workshop: Is to provide the participants with knowledge on how to monitor and tune performance of Microsoft SQL Server 2005. The course addresses CPU, Memory, Disk, Query and Lock monitoring and Tuning techniques. Best practice guidelines for configuration and maintenance are covered. After the workshop, the attendees should be able to identify and tune performance issues.

 

 

 

Prerequisite: This is a level 400 technical workshop, basic prior SQL Server experience(knowledge about Cluster, Heap and Non-cluster index, Index Tuning Wizard, SQL Profiler) is necessary.

 

 

 

Lab exercises: Yes

 

 

 

Level\Depth: 400 (of 400 possible)

 

 

 

When & Where: Training is held on November 19th – November 21st, from 9am to 4.30pm each day, in Microsoft’s office located at Lilleakerveien 6, Oslo; http://www.microsoft.com/norge/about/contact.mspx If high demand, we might change to another location in Oslo. If so happens, we will inform you accordingly as soon as possible. This training is delivered in English.

 

 

 

Cost & Availability: This course is special made by Microsoft Services and is delivered only by Microsoft, for our Premier Support customers only. Price are 18 proactive hours from your Premier Support contract, per attendee, or NOK 27.500,- if you do not have any proactive hours available or choose not to use them. Lunch will be served every day of training. Any other costs for attending must be covered by yourself.

 

 

 

Enrolling: By default we have 12 available seats for this training, and -1- seat for each Premier Support customer. If you wish to enroll more than -1- person, please contact your TAM/ADC. We will confirm your seat(s) as soon as possible, no later than 7 days before class begin. Enrollment is binding and is done by contacting your TAM/ADC no later than November 12th.

 

 

 

Should you have any inquiries to this training or any other offerings from Microsoft Services, I will answer you as soon as possible.

 

 

 

 

 

Best regards / Med vennlig hilsen,

 

Chato Müller

 

Technical Account Manager

SQL_Server_2005_Performance_Tuning__level_400_.pdf

Endret 13. november 2007 av kaffenils