Vanuit een intern perspectief zijn de methoden in wezen hetzelfde.
Achter de schermen, wanneer u een op datum gebaseerde partitie maakt, maakt de SQL-engine afzonderlijke fysieke tabellen voor elke partitie en doet vervolgens wat in feite een UNION is wanneer u de tabel zelf opvraagt.
Als u een filter gebruikt in uw query op de gepartitioneerde tabel die overeenkomt met uw partitioneringsveld (DateField laten we zeggen), dan kan de engine direct naar de partitie gaan die je nodig hebt voor de data. Zo niet, dan doorzoekt het elke fysieke tabel in de logische tabel om de zoekopdracht te voltooien.
Als uw vragen een datumfilter bevatten (wat lijkt op uw vraag), dan kan ik geen voordeel bedenken voor uw "aangepaste" methode.
In wezen is de keuze die u moet maken wilt u verantwoordelijk zijn voor alle logica en hoekzaken die betrokken zijn bij partitionering, of wilt u de ontwikkelaars bij Microsoft vertrouwen die dit al tientallen jaren doen om het voor u te doen?
Voor mijn eigen doeleinden, als er een ingebouwd raamwerk is voor iets dat ik wil doen, probeer ik het altijd te gebruiken. Het is altijd sneller, stabieler en minder foutgevoelig dan een "roll-your-own"-oplossing.