FAQ |
Kalender |
![]() |
#9 | ||
|
|||
Klarade millennium-buggen
|
Först skapar vi databasstrukturen med DDL-script...
Kod:
delimiter $$ CREATE TABLE `naak2803postnrarea` ( `id` int(11) NOT NULL AUTO_INCREMENT, `postnr` varchar(11) NOT NULL, PRIMARY KEY (`id`) ) ENGINE=InnoDB AUTO_INCREMENT=5 DEFAULT CHARSET=latin1$$ Kod:
INSERT INTO `wn`.`naak2803PostnrArea` (`id`, `postnr`) VALUES ('1', '75000-76000'); INSERT INTO `wn`.`naak2803PostnrArea` (`id`, `postnr`) VALUES ('2', '11655-11660'); INSERT INTO `wn`.`naak2803PostnrArea` (`id`, `postnr`) VALUES ('3', '77998'); INSERT INTO `wn`.`naak2803PostnrArea` (`id`, `postnr`) VALUES ('4', '45770'); Kod:
-- -------------------------------------------------------------------------------- -- Routine DDL -- Note: comments before and after the routine body will not be stored by the server -- -------------------------------------------------------------------------------- DELIMITER $$ CREATE PROCEDURE `wn`.`GetPostnrArea`(IN pnr VARCHAR(5)) BEGIN SELECT * FROM `wn`.`naak2803PostnrArea` WHERE postnr LIKE '%-%' AND SUBSTR(postnr, 1, 5) <= pnr AND SUBSTR(postnr, 7, 5) >= pnr UNION SELECT * FROM `wn`.`naak2803PostnrArea` WHERE SUBSTR(postnr, 1, 5) = pnr; END Kod:
delimiter $$ CREATE DEFINER=`root`@`localhost` PROCEDURE `GetPostnrAreaTest`() BEGIN call `wn`.`GetPostnrArea`('75005'); -- Area 1 75000-76000 call `wn`.`GetPostnrArea`('11657'); -- Area 2 11655-11660 call `wn`.`GetPostnrArea`('77998'); -- Area 3 77998 call `wn`.`GetPostnrArea`('45770'); -- Area 4 45770 call `wn`.`GetPostnrArea`('55555'); -- No area SELECT 'Tartaren' as code, x.* FROM wn.naak2803PostnrArea x WHERE postnr LIKE '%-%' AND SUBSTR(postnr, 1, 5) <= '75005' AND SUBSTR(postnr, 7, 5) >= '75005'; END$$ Kod:
call `wn`.`GetPostnrAreaTest`(); Jag har utgått från tartarens grundlösning och kompletterat den efter vad jag tror är den fullkomliga lösningen av problemdefinitionen. Jag håller dock med Tartaren och andra i tråden om att datamodellen inte är normaliserad ens med 1NF (Första normalformen) då postnr-kolumnen inte är atomär. Det i sig gör det extremt svårt att bygga en effektiv lösning. Risken för bristande datakvalitet är uppenbar. Senast redigerad av Conny Westh den 2013-02-01 klockan 22:40 |
||
![]() |
![]() |
|
|