Зачем вам может понадобиться SITE_ID в настройках Django

[Hellpain]

Нерасширяемое, неуправляемое дополнение, которое стоит выкинуть вместе с flatpages.
Переопределние objects в модели — bad practise.

Те, кому это нужно реализовать подобную функциональность, сделают это через свои модели, менеджеры и мидлвари без привязке с закостеневшей логике.

[danilovmy]

hellpain а как тогда лучше сделать, если не объявлять objects у класса, чтобы не bad?

[xammi-1]

Не совсем понял про objects, однако согласен со второй частью комментария.

На своих проектах делаю так:

# models.py -------------------------
class Site(models.Model):
    # название, куча вспомогательных полей
    domain = models.CharField(...)

class Info(models.Model):
    # куча информационных полей
    site = models.ForeignKey(Site, ...)

# middlewares.py -------------------------
class SiteMiddleware(models.Model):
    def process_request(self, request):
        domain = request.META['HTTP_HOST']
        site = Site.objects.filter(domain=domain).first()
        if not site:
            raise Http404()
        setattr(request, 'site', site)

# views.py -------------------------
class IndexView(ListView):
    def get_queryset(self):
        return Info.objects.filter(site=self.request.site)

[danilovmy]

xammi-1, сейчас все именно так, думаю, у большинства. И у меня тоже так было.
Идея, которую не доделали в CurrentSiteManager, в том, что в для IndexView достаточно тогда только указать:

class IndexView(ListView):
    model = Info

Остальное должен был бы сделать CurrentSiteManager, если б он правильно работал с рождения. Но увы, пришлось его допилить, но теперь у меня в проектах нет ни одного filter(site=self.request.site)

Согласен со всеми комментаторами, что:

сделают это через свои модели, менеджеры и мидлвари

a от Django у меня остались лишь рожки да ножки названия и идея.

[arheops]

А зачем вообще все пихать в одну базу? Какие преимущества по вашему?
С одной админкой(если уж сильно надо) много чего можно сделать, к примеру, есть router для db.