C, PHP, VB, .NET

Задача 1. Да се проектира база от данни за оффроуд състезание. В базата данни се пази информация за екипажите: стартовия номер, имената на пилота и щурмана, марката и модела на автомобила, и кръвните групи за всеки член на екипажа. Състезанието е разделено на различни етапи. В статистическата информация се пази времето на старта,     и времето на пристигане за всеки етап, на всеки автомобил. За всеки етап се пази присъдената му категория сложност от 1 до 10. За всеки етап от състезанието се назначава специален автомобил наречен „евакуатор“, който оказва техническа и медицинска помощ на повредени и катастрофирали автомобили. Също така за всеки етап се записва съдия, който регулира състезанието. Прочети още…

.

Нека разгледаме следните примерни две таблици: Прочети още…

.

Въпросът поставен в заглавието на статията е много често разискван и около него се водят спорове. По принцип има една тенденция програмистите категорично да избягват вложените select заявки, защото още от миналото има един мит, че те се изпълняват бавно. Този мит се дължи главно на грешки в СУБД, които не са използвали правилно индексите при вложените заявки. Днес това отдавна вече (почти) не се среща, т.е. можем да очакваме вложените заявки да вървят достатъчно добре. Така въпросът „join или вложен select“ отново стои на дневен ред.

Ще демонстрираме с един пример. Нека имаме следната база от данни: Прочети още…

.

В предишна статия свързана с ограниченията CHECK писахме за нещо изключително неприятно – не се поддържат от MySQL. В същия момент именно CHECK понякога е доста важно за интегритета на данните когато пишем в „несигурна среда“, т.е. работим с програми, на които не можем да вярваме. Прочети още…

.

Още в началото, когато се разглеждаха заявки за еднотабличен оператор SELECT, набързо се разгледа оператор LIMIT. Да припомним – той приемаше за параметър целочислено число X, чрез което от резултатната таблица се връщат само първите X реда, а останалите „се отрязват“. Това естествено има редица приложения – разглеждане на най-новите записи от статистики, разглеждане на „най-добрите“ резултати от състезание, извеждане на последните записи в таблица и т.н. Почти винаги, за такива случаи, оператор LIMIT е предхождан от ORDER BY. Прочети още…

.

В статията за вложен SELECT представихме едно допълнение към ER диаграмата за база от данни на университет. Да припомним – проблемът беше, че в оригиналния ER модел връзката между студенти и факултети минаваше през записани учебни предмети. Така ние нямаше възможност да разберем от кой факултет е даден студент, ако той не е записал нито един учебен предмет. Предложеното решение беше да пазим допълнителен външен ключ от таблицата „студенти“ към таблицата „факултети“: Прочети още…

.

В досега разглежданите примери при CREATE TABLE на няколко пъти показвахме параметър „UNIQUE“, който се добавяше след дадена променлива. Например:

CREATE TABLE university(
   `id` INT UNSIGNED AUTO_INCREMENT,
   `name` VARCHAR(255) NOT NULL UNIQUE,
   PRIMARY KEY(id)
)ENGINE=INNODB;

Казахме, че PRIMARY KEY винаги е едновременно NOT NULL и UNIQUE по подразбиране, както и че е възможно да направим комбинация от две или дори повече колони заедно PRIMARY KEY. Прочети още…

.

Нормализацията на бази от данни е една изключително важна тема, която обаче е по-теоретично насочена и поради тази причина не наблягахме досега на нея. Текстът по-долу е реферат на студента Никола Костадинов Симеонов, който смятам, че много добре описва темата „нормализация на бази от данни“…

тема:

До къде може да стигнем с номализацията?

Никола Костадинов Симеонов, ТУ-София, ФКСУ, гр. 57

Прочети още…

.

Представената по-долу статия е написана във вид на реферат от студентката Павлина Темелакиева от Технически Университет – София.

Тема:

„Постигане на висока производителсност
на базата данни чрез разделяне на части“

Павлина Евгениева Темелакиева, ТУ – София , ФКСУ, гр. 63А

Прочети още…

.

След като научихме заявките, използващи UNION, вече сме готови да посочим как се прави и липсващия в MySQL FULL JOIN. Ще използваме таблиците с плодове и зеленчуци от предишната статия.

Нека припомним как работеха LEFT и RIGHT JOIN. За целта ще направим многотаблична заявка по колоната „цена“: Прочети още…

.