To nadal często zbiera dodatkowe głosy, nawet kilka lat później, więc muszę zaktualizować go do nowoczesnych wersji Sql Server. W przypadku SQL Server 2008 i nowszych to proste:
cast(getDate() As Date)
Zwróć uwagę, że ostatnie trzy akapity u dołu nadal obowiązują i często musisz zrobić krok wstecz i znaleźć sposób na uniknięcie rzutu.
Ale są też inne sposoby, aby to osiągnąć. Oto najczęstsze.
Właściwy sposób (nowość od SQL Server 2008):
cast(getdate() As Date)
Właściwy sposób (stary):
dateadd(dd, datediff(dd,0, getDate()), 0)
To jest teraz starsze, ale nadal warto o tym wiedzieć, ponieważ może również łatwo dostosować się do innych punktów czasowych, takich jak pierwsza chwila miesiąca, minuta, godzina lub rok.
Ten poprawny sposób wykorzystuje udokumentowane funkcje, które są częścią standardu ansi i gwarantują działanie, ale mogą być nieco wolniejsze. Działa, wyszukując liczbę dni od dnia 0 do dnia bieżącego i dodając tę liczbę dni wstecz do dnia 0. Będzie działać bez względu na to, jak przechowywana jest data i godzina oraz bez względu na ustawienia regionalne.
Szybki sposób:
cast(floor(cast(getdate() as float)) as datetime)
Działa to, ponieważ kolumny daty i godziny są przechowywane jako 8-bajtowe wartości binarne. Rzuć je tak, aby unosiły się w powietrzu, wyrównaj je, aby usunąć ułamek, a część czasowa wartości zniknie, gdy przerzucisz je z powrotem na datę i czas. To wszystko tylko trochę się zmienia, bez skomplikowanej logiki i jest bardzo szybki.
Należy pamiętać, że zależy to od szczegółów implementacji, które firma Microsoft może zmienić w dowolnym momencie, nawet w przypadku automatycznej aktualizacji usługi. Nie jest też zbyt przenośny. W praktyce jest bardzo mało prawdopodobne, że ta implementacja zmieni się w najbliższym czasie, ale nadal ważne jest, aby zdawać sobie sprawę z niebezpieczeństwa, jeśli zdecydujesz się z niej skorzystać. A teraz, gdy mamy możliwość rzucania jako daty, rzadko jest to konieczne.
Niewłaściwy sposób:
cast(convert(char(11), getdate(), 113) as datetime)
Niewłaściwy sposób polega na konwersji na ciąg, obcinaniu ciągu i konwersji z powrotem na datę i godzinę. To złe , z dwóch powodów:1) może nie działać we wszystkich lokalizacjach i 2) jest to najwolniejszy możliwy sposób... i nie tylko trochę; to jak o rząd wielkości lub dwa wolniej niż inne opcje.
Aktualizacja Ostatnio otrzymało to trochę głosów, więc chcę dodać do tego, że odkąd to opublikowałem, widziałem całkiem solidne dowody na to, że SQL Server zoptymalizuje różnicę wydajności między "poprawnym" sposobem a "szybkim", co oznacza, że powinieneś teraz faworyzować to pierwsze.
W obu przypadkach chcesz pisać swoje zapytania, aby uniknąć konieczności robienia tego w pierwszej kolejności . Bardzo rzadko należy wykonywać tę pracę na bazie danych.
W większości miejsc baza danych jest już Twoim wąskim gardłem. Ogólnie rzecz biorąc, to serwer jest najdroższy do dodania sprzętu w celu poprawy wydajności i najtrudniejszy do uzyskania odpowiednich dodatków (musisz na przykład zrównoważyć dyski z pamięcią). Najtrudniejsze jest również skalowanie na zewnątrz, zarówno z technicznego, jak iz biznesowego punktu widzenia; technicznie znacznie łatwiej jest dodać serwer WWW lub serwer aplikacji niż serwer bazy danych, a nawet jeśli to nieprawda, nie płacisz ponad 20 000 USD za licencję serwera dla IIS lub Apache.
Chodzi mi o to, aby zawsze, gdy to możliwe, wykonywać tę pracę na poziomie aplikacji. tylko czas, w którym powinieneś kiedykolwiek znaleźć się na obcinaniu daty i godziny na serwerze Sql Server, jest wtedy, gdy musisz grupować według dnia, a nawet wtedy prawdopodobnie powinieneś mieć dodatkową kolumnę ustawioną jako kolumnę obliczaną, utrzymywaną w czasie wstawiania/aktualizacji lub utrzymywaną w aplikacji logika. Pobierz tę łamiącą indeksy, obciążającą procesor pracę ze swojej bazy danych.
