всего то

ты спросил что быстрее, а что медленнее

значит неправильно спросил

1,2,3,4,5,6 date-time-1, date-time-2, date-time-3

да, так быстрее, id вместо даты

очевидно, что циферки сравнить и отсортировать будет быстрее

а что экономнее? take или limit?

хз - смотри на реализацию методов

через отладчик смотри на скорость

эх, пока не умею им пользоваться. ну ладно, спасибо все равно

Да просто к базе подключиться и посмотреть, что туда летит

Ещё проще debugbar подцепить

Все будет одинаково в запросе /** * Alias to set the "limit" value of the query. * * @param int $value * @return \Illuminate\Database\Query\Builder|static */ public function take($value) { return $this->limit($value); } take вызывает limit из доков видно, что это просто алиас лимит

Model::orderBy('id', 'DESC')->limit(5)->get()

Model::orderBy('id','desc')->take(5)->get() это медленнее?

не бойтесь смотреть исходниики ) там полная картина реализация, не высветленная в доках )

не бойтесь смотреть исходниики ) там полная картина реализация, не высветленная в доках )

спасибо)

как по мне предпочтительное limit, вместо take, сокращение вызовов

где-нибудь есть хорошая статья про uuid vs increment?

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

Если нет нужды объединять таблицы, БД, то зачем отказываться от auto increment?

незачем

и если прям сильно подожмет, ничто не мешает заменить id на uuid

ну подумаешь запрос часик будет выполняться, чо такого

ну, если таблица здоровая

и ничто не мешает юзать их вместе

потому что тебе может понадобиться сортировка или что-то такое

для сортировки можно вкорячить sort

но все равно, когда мне заранее известны id, то некоторые вещи можно делать проще

особенно если модельки сложные

ага

поэтому пожалуй да, если и делать uuid, то лучше совмещать с id

а не взаимозаменять

есть еще timeuuid, по нему и сортировать можно

Привет всем! Вакансию Fullstack сюда прилично запостить ?

да

@webwork @web_work

желательно сюда

Настали тяжёлые времена?

Настали времена банов

Настали времена банов

Почистил

кто-нибудь блейд ковырял?

шаблонизатор-то?

да

кто-нибудь блейд ковырял?

В смысле?

в прямом

там довольно забавные конструкции, но суть не в этом

почему @extends такой ущербный >_<

сделай свой с куртизанками

а что с ним не так?

там де легко достаточно конструкции свои писать

а что с ним не так?

то что он всегда работает из root директории

http://platesphp.com/

а не из директории, где вызывается

и это не особо доставляет, потому что когда пишешь свою структуру директорий, приходится писать костыли

или может я чего-то не понимаю?

странно, у меня таких проблем не было

@extends('layouts.master') - дергает /resources/views/layouts/master.blade.php

@extends('layouts.master')

ну да, все верно

а как хочешь?

видимо относительные

т.е. в моем случае мне придется прописать что-то типа @extends('Modules.User.Resources.views.PersonalArea.layouts.master')

длинновато, вам не кажется?)

кажется, но это твой выбор делать модульность, ты с ним и страдай)

или пили свой extends

а twig как работает?

не трогал

хочется уже выкинуть модульность и посмотреть в сторону других подходов

не может же быть такого, что бы нельзя было элегантно большую приложуху на ларе запилить

сколько у тебя модулей?

тебе нужна именно модульность? чтобы выкинув один модуль приложение продолжало работать? или просто структурировать код надо?

пока что - 0

надо структурировать

ну распихивай просто по папочкам

не в app

но это же будет ппц

а все на своих местах

представь если у меня сотня папок

а сотня модулей?