почти*

Но тебе всё равно нужно колонки явно перечислять. * не прокатит. Потому что тебе нужно помимо удаления лишних их все проименовать правильно. Иначе ты JSON не сформируешь.

Вот так никак не получить?

Во, вроде норм?

select s.week_name, s1.value as cl_1, s2.value as cl_2, s3.value as cl_3, s4.value as cl_4 from schedule s left join sublect s1 on s1.subject_id = s.cl_1_id left join sublect s2 on s2.subject_id = s.cl_2_id left join sublect s3 on s3.subject_id = s.cl_3_id left join sublect s4 on s4.subject_id = s.cl_4_id order by s.id

только сортировку лучше по id сделать

иначе вторник раньше понедельника будет

только сортировку лучше по id сделать

А я знаю, где там у него ID ?

А, да

ну в картинке был вроде

трындец говнище...

(более подходящей нет)

Еее

Ты топ

Спасибо огромное)

И без сортировки кстати норм

Но ты про нормализацию почитай все же

Да тут не тот случай...

Ой да ладно)

Тут надо БД с нуля учить

И без сортировки кстати норм

Запомни, сынок, БЕЗ СОРТИРОВКИ ЗАПРОС — ГОВНО!

У меня задания сортируются по сложности, так что не надо мне тут)

трындец говнище...

А еще если фильтры появялтся, типо, дни где есть "Математика" И начнется - "OR ...OR ...OR ...OR" или схожие по уродству альтернативы

Ну там должен быть фильтр по текущей неделе, либо по номеру недели сортировка в начале

Может кто-то хочет предложить наилучшую архитектуру?)

Тебе ж предлагали схему прислать...

Вроде бд не сложная

Я чет пропустил

Вот и пошли.

Скинь что там сейчас у тебя в структуре

вот

Кароч, всем участникам спасибо) Если нужна будет помощь по Java/Android - спрашивайте

только сортировку лучше по id сделать

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

ну в данном примере - они идут так, как ему надо

а так - да. и вывод без сортировки тоже может быть не по id отсортирован

Переписал код возникли проблемы с добавление. Можно ли при такой связи удалить CREATE TABLE flavor ( name TEXT, drops INTEGER, recipeid INTEGER REFERENCES recipe (flavorid) );

recipeid INTEGER REFERENCES recipe (flavorid) — НА PK ссылайся.

recipeid INTEGER REFERENCES recipe (flavorid) — НА PK ссылайся.

С ПК все ок, но становиться проблема в добавлении данных

какая ?

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

Надо узнать...

Вставил — узнай ID

Потом уже вставлять во flavor table?

Ну да.

Или у тебя свой вариант решения проблемы имеется ?

ИЗложи

Я писал уже. Две ф-ции с 2 DETELE FROM

Сначала удалить из recipe таблице потом из flavor

"Переписал код возникли проблемы с добавление.", "Сначала удалить из recipe таблице потом из flavor" - -тебя блин не поймёшь

"Переписал код возникли проблемы с добавление.", "Сначала удалить из recipe таблице потом из flavor" - -тебя блин не поймёшь

Я хотел удалять одним DELETE FROM recipe WHERE recipeid = ?

В смысле я лично не понимаю, в чём твоя проблема. Если хочешь чтобы тебе помогли, наверное надо как-то объяснить

теперь будет два DELETE FROM flavor WHERE flavorid=?

В смысле я лично не понимаю, в чём твоя проблема. Если хочешь чтобы тебе помогли, наверное надо как-то объяснить

+

Поставлю вопрос так, реально ли удалить не ссылаясь на пк?

Причем значение на которое я ссылаюсь unique

что откуда как ... блин вытягивать из тебя всё надо или как ?

В тот момент когда он сможет обьяснить что ему нужно... он и сам поймет как это сделать.. :) ибо правильный вопрос это уже 99% ответа.

Короче, он очень боялся вставить значение в PK, и не знал, как же его получить обратно после вставки.

При этом что=то типа AUTOINCREMENT или IDENTITY у него на поле PK не стояло.

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

Сошлись на том, что можно это "случайное" значение вставлять и в PK, а другая колонка тогда не нужна.

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

uuid же блеать

NO UUID!

Да я чё, за него буду его БД проектировать ?

а чо ты за него ее проектируешь?

(:

Не знаю... Связался вот...

руки помой

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

а чо, сап предлагает делать к сибе интерфейсы на ангуляре?

чиво

https://www.sap.com/developer/tutorials/angular-getting-started.html

И зачем нам это здесь

И зачем нам это здесь

Сектанты, сэр...

Задачка.нужно изменить логику вычисления даты выезда: если после выезда а/м в течение 2 часов есть въезд, отбрасываем этот выезд и проверяем аналогично следующий если после выезда в течение 2 часов нет обратного въезда, этот выезд нас устраивает, и мы возвращаем его дату Вопрос: Нужно через цикл прогонять или есть ф-ия (sql server)

Нужно через запрос прогонять

выезд inn left join въезд outt on <разница не больше 2 часов> where outt.pk is null

Или аналогичный NOT EXISTS

выезд inn left join въезд outt on <разница не больше 2 часов> where outt.pk is null

Представил такой запрос на базу из десятка миллионов строк... понял почему столько датацентров кругом.

А что тебя смущает в запросе ?

Это вычитание, по-любому небыстро, но с индексом вполне себе сносно будет работать

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

Зачем join, когда время въезд/выезд можно хранить в 2х полях одной записи?

Выехал - заполнил поле выезд, въехал - поле въезда

Тогда не будет нескольких въездов или выездов одной и той же машины подряд

А что тебя смущает в запросе ?

Меня смущает то что пытаются на базу переложить то что может приложение сделать. И получают страшно тормозную хрень которую компенсируют железом

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

Тогда не будет нескольких въездов или выездов одной и той же машины подряд

У тебя машина может выехать несколько раз подряд не въехав ниразу?